Instatic CMS: The Self-Hosted Alternative to Webflow and WordPress

Every website builder eventually asks you to trade something for convenience. WordPress asks you to manage plugins and hosting yourself. Webflow asks you to pay a monthly fee forever and keep your content on their servers. Framer asks the same, with a smaller export door. Somewhere along the way, "easy to build" started meaning "hard to leave."

Instatic is a new open-source CMS from the team behind Motion.page and Core Framework, built around a different bet: that a site should be fast to build, genuinely yours, and boring to maintain, all at once. It's MIT-licensed, self-hosted, sits at version 0.0.10 on GitHub, and has already crossed 2,400 stars. We went through its architecture, its editor, and its plugin model in detail. Here's what agencies and founders evaluating it need to know.

What Instatic actually is

Most modern site stacks are assembled, not built:

• A headless CMS holds the content
• A framework like Next.js renders it
• A host like Vercel serves it
• A form service handles submissions
• An image CDN optimizes media

Each piece has its own dashboard, its own bill, and its own way of breaking at an inconvenient hour.

Instatic collapses that stack into one Bun server. The visual editor, content engine, media handling, authentication, forms, plugins, and publisher all live in a single instance, backed by SQLite for a single site or Postgres when a team needs managed backups and multiple authors. There's no separate rendering layer to configure and no second vendor to onboard just to collect a contact form submission.

The output is the part that usually gets compromised first when a builder chases ease of use. Instatic publishes plain, semantic HTML and a compact CSS file:

• No React shipped to the visitor
• No builder-specific data attributes cluttering the markup
• No div soup

Open view-source on a published Instatic page and you'll see something a developer would be comfortable writing by hand, the same standard we hold our own web development and engineering builds to.

Dynamic content doesn't break that promise either. Instatic bakes pages to static files on disk the moment you publish, and swaps them in atomically so nobody sees a half-updated page. For the pieces of a site that genuinely need to be dynamic, like a comment count or a logged-in state, it detects those spots automatically and loads them through a runtime that weighs about 0.7 kB. Everything else is a file sitting on disk, served the way a static file is served, because that's what it is.

The visual builder: closer to Figma than to a form

Most page builders are a form with a live preview stapled next to it. Instatic's canvas works more like a design tool.

Multi-breakpoint editing. Place Desktop, Tablet, and Mobile frames side by side and watch a layout change cascade across all three as you edit. Live Mode drops you into a single full-size viewport when you want to focus on precision work.

A layer panel that shows the real DOM. It exposes the actual document structure, with distinct visual badges for sections, divs, articles, and other node types. What you build on the canvas maps directly to the semantic HTML that ships, which is a deliberate constraint: it's much harder to accumulate div soup when the editor keeps showing you the real structure as you work.

Visual Components. Reusable pieces carrying typed parameters, strings, numbers, booleans, colors, images, URLs, rich text, enums, and named slots for nested content. Edit a component once and every instance across the site updates. Components can't reference themselves, so there's no risk of an accidental infinite loop eating the page.

Templates and Loops. Templates handle shared chrome: one layout for the whole site, separate layouts per post type, and a real 404 page you design yourself rather than inherit from a default. Content flows into an outlet, so the header and footer get written once and wrap everything downstream. Loops repeat a layout over a collection, your posts, your pages, your media, or anything a plugin exposes as a source, and can alternate between two or three variants as they run, which is how you get a post grid that doesn't look like the same card copy-pasted forty times.

Import that holds up. Paste raw HTML and it becomes editable nodes. Drop a full static site as a zip, HTML, CSS, fonts, images included, and Super Import parses the folder, splits it into components, extracts design tokens, and organizes the CSS selectors into the framework. Every conflict is surfaced before anything gets written, and the whole import undoes as one action if something looks wrong.

Core Framework, wired in rather than bolted on

The detail that separates Instatic from a typical page builder is Core Framework, a design-token engine that thousands of WordPress professionals already rely on through tools like Bricks and Oxygen. Here it isn't a plugin you install and hope plays nicely. It's a core system the whole editor is built around.

• Color tokens. Define one brand color and Instatic generates the full scale of tints and shades on its own.
• Fluid type and spacing. Typography and spacing aren't forty hand-picked pixel values you keep in sync across breakpoints; they're a mathematical scale that flows with the viewport.
• Selector management. A dedicated panel shows every utility class the framework has generated, flags the ones nothing is using, and renames a class globally from one search field.

The effect is that a site's whole design system lives as data. Change a token once and every page using it updates, the same principle behind the component system applied to color, type, and spacing instead of layout. It's also the kind of system-first thinking we bring to branding and visual identity work, where a token change should never mean a manual pass through forty pages.

One content model, not a "pages" table with duct tape

Instatic doesn't treat pages as a special case with everything else bolted on around it. Pages, posts, components, and any custom collection you invent all live in the same two tables under the hood, data_tables and data_rows. That sounds like an implementation detail until you try to build something a typical CMS doesn't anticipate: a property listing, a product catalog, a testimonials table, a lightweight CRM fed by a form.

At /admin/data, you define custom post types and plain data tables with their own fields, then work the rows in a spreadsheet-style grid, search, sort, filter, bulk publish, bulk export. Custom post types come with a real editorial workflow, draft, scheduled, published, plus version history on what's live. Every table you build becomes a source a Loop can render, so a "Team" table defined once can populate a grid on the about page without any custom code.

Writing happens in a Gutenberg-style block editor with slash commands for text, tables, loops, and images, plus native SEO fields for slug, title, meta description, and featured image, so an agency isn't bolting on a separate SEO plugin to get the basics right. That's the foundation layer we build on for content and authority building work, where the CMS shouldn't be the thing slowing an editorial calendar down.

Forms skip the third-party service entirely. Build one from semantic fields on the canvas, and Instatic reads the fields you placed and creates the matching data table automatically. Submissions land in your own CMS, not a vendor's dashboard you're paying a monthly fee to access, which matters once you're running conversion rate optimization tests and need raw access to every submission field, not an export button behind a paywall.

Media is handled like an actual file manager rather than a flat upload list: folders and smart folders, usage tracking so you know where an image is actually referenced before you delete it, replacement workflows, and pluggable storage adapters for when local disk isn't enough.

AI that edits the page, not just the copy

Instatic ships an AI agent that works directly on the canvas rather than generating a block of text you have to paste in. Ask it for a pricing table and it writes the actual semantic HTML nodes and CSS tokens into the editor, through the same import pipeline used for pasted markup, so what it creates is editable exactly like anything you built by hand.

It runs on a bring-your-own-key model across a 35-tool Site Scope and a 15-tool Content Scope:

• Supports Claude, OpenAI, OpenRouter's catalog of 400-plus models, or a fully local Ollama setup
• No markup on top of API usage, no subscription tier for AI access
• Model Context Protocol support means the CMS can also be driven from an external client like Claude Desktop

That last point overlaps directly with the kind of AI agents and autonomous workflow systems we build for clients who want their tools talking to each other without a human relaying messages between them.

Security and permissions built for agencies managing client sites

Anyone who has handed a client access to a page builder knows the risk: one wrong click and a client "helpfully" breaks the layout two days before launch. Instatic's role system is built around that exact problem.

• Owner and Admin roles get full access.
• Client role can edit text and write posts but is locked out of dragging modules, altering the DOM, or touching the design framework.
• Underneath sits a capability system with 36 discrete permissions, token-based sessions, TOTP two-factor with secrets encrypted at rest, account lockout with backoff after repeated failed logins, and step-up confirmation prompts before destructive actions like deleting a user.
• Every meaningful admin action, a login, a content change, a role edit, a plugin install, writes an append-only row to an audit log. Nobody can quietly rewrite the record of who did what.

Plugins get the same restraint. Where a WordPress plugin typically runs with root-level access to the whole server, an Instatic plugin runs inside a QuickJS-WASM sandbox with no filesystem access, no environment variables, and no network calls unless the site owner grants a specific host. A plugin can't read your secrets or phone home, because the sandbox never gives it the door in the first place. Inside that sandbox, plugins can still add HTTP routes, admin pages, scheduled jobs, new canvas modules, loop data sources, and media storage adapters, so the restriction limits blast radius without limiting what's actually buildable.

Deployment: one Docker image, no vendor holding the keys

Instatic deploys to Railway in one click, provisioning the database, secret keys, and storage volume automatically, no terminal required. It's also packaged as a single Docker image for anyone who wants it on their own VPS, with full guides for Postgres, HTTPS via Caddy, Render, and backup and restore.

Updating means pulling the latest image. The database and uploads sit on an attached volume, so the app container can be replaced without touching the live site's data. Back up the database and the uploads folder, and you've backed up the entire site. There's no separate CDN account, no headless CMS subscription, and no framework hosting bill layered on top.

Built to be found: SEO, AEO, and GEO in one architecture

Most CMS platforms treat search visibility as something you add afterward, a plugin here, a schema generator there. Instatic's architecture gets you most of the way to all three layers of modern search, traditional SEO, answer engine optimization, and generative engine optimization, without a single third-party add-on.

SEO (Search Engine Optimization)

• Native fields for URL slug, SEO title, meta description, and featured image on every post and page, no Yoast or RankMath equivalent required
• Real semantic tags, article, section, nav, aside, assigned through the Layer Panel instead of leaving crawlers to guess at div-based layout
• Static HTML output with minimal JavaScript, so Core Web Vitals like Largest Contentful Paint and Interaction to Next Paint land in good territory by default
• Media Workspace filters that flag images missing alt text, covering accessibility and image search indexing in the same pass

AEO (Answer Engine Optimization)

Answer engines like Perplexity and Google's AI Overviews read the DOM to work out which heading owns which paragraph, and they often give up on pages that need JavaScript to render at all.

• A static HTML payload sidesteps that failure mode: the full text sits in the source the moment a crawler requests the URL, no rendering step required
• The same clean markup that makes a page easy to read in view-source is what makes it easy for a language model to parse without tripping over layout wrappers
• Even the "dynamic holes" used for database-driven content, like a property listing or blog grid, are filled server-side, so an answer engine always sees a complete document rather than a half-loaded shell

GEO (Generative Engine Optimization)

Getting cited inside an AI-generated answer, rather than just ranked in a list of links, asks for structured data and extractable formats.

• Raw control over the head of your templates means JSON-LD for Article, FAQPage, or Organization schema can be mapped straight from your custom data tables, instead of routed through a plugin that half the time produces conflicting markup
• Visual Components paired with data loops mean a standardized FAQ accordion or comparison table can be built once and populated with facts across hundreds of pages, exactly the table-and-list format generative models tend to lift into their answers

None of that replaces a strategy. A CMS can hand you clean markup and still get zero citations if the content underneath has nothing worth citing. That's the layer our SEO and AI search visibility work sits on top of: Instatic removes the technical excuses, and the strategy decides what actually gets found.

Why this matters for code sovereignty

This is the part that lines up directly with how we think about building sites at Orion Corps. Code sovereignty means a client owns their code, their content, and their infrastructure outright, with nothing standing between them and the ability to move, rebuild, or walk away on their own terms.

Most of the tools that dominate the "modern website" conversation quietly work against that:

• Webflow and Framer keep your site running on their infrastructure for a recurring fee, and the moment that fee stops, so does the site
• WordPress gives you ownership on paper but leaves you exposed to a plugin ecosystem that runs with far more access than it should have

Instatic's architecture makes sovereignty the default rather than an afterthought:

• The output is HTML and CSS anyone can read, host anywhere, and take with them, not markup wrapped around a proprietary runtime
• The whole site's data, pages, posts, custom collections, form submissions, lives in a SQLite file or Postgres database you control, not a vendor's API you're renting access to
• Plugins can't quietly exfiltrate data because the sandbox never gives them a network connection unless you explicitly grant one
• Because it's a single Docker image, moving it from Railway to a VPS to a client's own server is a redeploy, not a migration project

For an agency building client sites, that changes what a handoff looks like. Instead of leaving a client dependent on a subscription and a vendor's roadmap, the deliverable is a system they actually own: their database, their uploads folder, their HTML. If Orion Corps builds on Instatic, the pitch we've been making about code sovereignty stops being a philosophy and starts being the literal architecture underneath the site.

Instatic is still in alpha (currently at version 0.0.10), and the team is upfront about it. Since it is an alpha release, you might encounter some minor hiccups, and APIs can shift before the stable release. The analytics piece of the product is still on the roadmap rather than shipped. For an agency willing to build alongside a young project, though, it's one of the few tools on the market where "you own your site" isn't a tagline bolted onto a subscription model. It's the actual design. The full source, docs, and release history are on GitHub.

Frequently Asked Questions