VelaFold CMS
Book a demo

CMS Core Laravel 13 · PHP 8.5

Move to a modern publishing core without losing the CMS data you already have.

VelaFold brings the public site, admin panel, block editor, media, SEO, security, backups and core updates together in one Laravel core. Your pages, languages and media records stay exactly where they are.

Book a demo Explore the Content API
  • Laravel ^13.8 / PHP 8.5
  • Multilingual publishing
  • OpenAPI 3.0 schema
  • Reversible core updates

Core

  • Laravel ^13.8
  • PHP 8.5
  • Blade theme layer
  • YAML block contracts
  • REST /api/v1
  • Sanctum content.write

What it solves

Content, operations and publishing in one core.

VelaFold respects the shape of your existing CMS data, then adds modern Laravel services, a theme layer and testable publishing workflows on top.

Legacy-aware core

Page, config, media, language, stats and navigation models stay intact. New layers work with the data you already have.

Block and theme system

YAML block contracts, Blade partials and theme overrides let teams manage the page experience one structured piece at a time.

Panel operations

Media, SEO, security, cron, backups, audit logs and the dashboard meet on one permission-aware surface.

Update discipline

Manifests, checksums, dry runs, backups, maintenance mode, patches and rollbacks turn updates into a controlled product flow.

Block editor

Content teams move faster without breaking code discipline.

The editor composes a page from blocks; behind every block sits a versioned YAML contract and a Blade partial.

  • Fields come from the schema. Every field in the editor is declared in YAML — no free-form HTML entry needed.
  • Theme overrides stay in code. The same block renders differently per theme while the content stays identical.
  • Preview is the real render. Share it before publishing via /api/v1/content/preview/{token}.
blocks/feature-grid.yaml 
name: feature-grid
label: Highlights
view: blocks.feature-grid

fields:
  - key: heading
    type: text
    translatable: true
  - key: items
    type: repeater
    max: 6
    fields:
      - { key: title, type: text }
      - { key: icon,  type: media }

# theme override: resources/themes/*/blocks

Public render

The public page is built from the same contract as the panel.

The page resolver, language service, block resolver, theme manager and SEO layer compose the public page together.

  • URLs are generated in one place. Panel, public site and API all use the same PageUrlService output.
  • Language is part of the content. Active site languages drive both the render and the API responses.
  • Switching themes never moves content. The Blade layer changes; the page data stays as it is.
resources/themes/default/blocks/feature-grid.blade.php 
{{-- Block data is validated against the schema --}}
<section class="feature-grid">
  <h2>{{ $block->heading }}</h2>

  @foreach ($block->items as $item)
    <article>
      @media($item->icon)
      <h3>{{ $item->title }}</h3>
    </article>
  @endforeach
</section>

Operations

The panel manages system health, not just content.

Security records, 404 behaviour, backup and restore, cron, queues, update packages and post-deploy health checks all live inside the same product mindset.

  1. Security

    Firewall, audit log, scans, whitelists, login attempts and 404 records make risk visible from the panel.

  2. Backup

    Local and Spatie backups, restore locks, progress state and the Drive broker are built into the flow.

  3. Cron & queues

    Scheduled jobs, queues, cache and the /api/v1/health probe are monitored from one place.

  4. Updates

    Signed metadata, an HMAC gateway, dry runs, manifest policy and rollback keep core files under control.

Dry run Every update is simulated before a single file is touched.
Checksum If the manifest and checksum disagree, the package is not applied.
Rollback With maintenance mode and a backup, a release can be reverted.

Content API

Public content speaks the same contract as the site.

Read endpoints are anonymous; write endpoints require a Sanctum bearer token with the content.write ability. The schema is published at /api/v1/openapi.yaml.

  • GET /api/v1/content/pages Published pages, filtered by language and type.
  • GET /api/v1/content/pages/{page} A single page: heading, blocks, media, taxonomy and SEO fields.
  • GET /api/v1/content/media Media records; individual access is by hash.
  • GET /api/v1/content/preview/{token} Tokenised preview of an unpublished revision.
  • GET /api/v1/health Post-deploy health probe.

Drafts, trashed items, future publications and expired records never leak into public responses under any condition.

GET /api/v1/content/pages?lang=en&type=service 
{
  "data": [
    {
      "title": "Services",
      "url": "https://site.com/services",
      "lang": "en",
      "content": {
        "blocks": [
          { "type": "hero" },
          { "type": "feature-grid" }
        ]
      },
      "seo": {
        "canonical": "https://site.com/services",
        "robots": "index,follow"
      }
    }
  ],
  "meta": { "total": 1 }
}

Fit

Who is VelaFold for?

Teams stuck on a legacy CMS

Years of accumulated pages, media and language data, where a clean install or a content migration is off the table.

Multi-site teams

Running one core across several domains and themes with a shared operations discipline.

Not a fit

Single-page marketing sites and fully headless, panel-free setups: VelaFold is heavier than those need.

FAQ

Frequently asked

Can I keep using my existing database as it is?

The VelaFold core was written to preserve the shape of legacy CMS tables: page, config, media, language, stats and navigation models work against your existing records. Before any migration we read your schema together and decide where VelaFold should take over.

Can my own team build themes and blocks?

Yes. A block is a YAML contract plus a Blade partial, and it can be overridden in the theme folder. For a team that knows Laravel there is no extra template language to learn.

What happens if a core update breaks the site?

Updates are simulated with a dry run first, the manifest and checksums are verified, a backup is taken and maintenance mode is engaged before anything is applied. If something goes wrong, the release can be rolled back.

How do Google Drive backups and Google sign-in work?

Those flows run through the VelaFoldAuth broker at auth.velafold.com. The panel requests only the scopes it needs for Google Sign-In, Drive backup storage and Calendar events; codes are single-use and expire in five minutes.

Can I reach the content from my own application?

Content API v1 read endpoints are anonymous and use the same URL and language contract as the public site. Write endpoints require a Sanctum token with the content.write ability. The OpenAPI 3.0 schema is published alongside the endpoints.

Let's read the data first, then talk about design.

We go through your current site, panel needs and publishing workflows together, then introduce VelaFold at the right boundaries.

hello@velafold.com VelaFoldAuth