Instatic Setup: Self-Host the Open Webflow Alternative

Instatic is a self-hosted CMS that puts the visual page editor, the content database, the media library and the publisher inside a single Bun server, and it added roughly 888 stars on Tuesday to reach about 5,950 total on GitHub trending. Give it fifteen minutes and you have a running admin at localhost:5173; give it a $6 VPS and a Docker compose file and you have a production site whose published pages are plain HTML you could read in view-source. The catch is the version number, and we will get to that.

• One process holds everything: canvas editor, content store, media, auth, forms, plugins and the static publisher. Data lives in SQLite by default, Postgres when you want it.
• Local setup is four commands and needs Bun and nothing else. No database server, no framework build to configure.
• Published pages ship semantic HTML and compact CSS with no editor runtime riding along, plus a roughly 1.1 kB script only where a page genuinely needs one.
• MIT licensed with no open-core tiers, but it is version 0.0.13, and the maintainers say APIs can still shift before 1.0.

What is Instatic and why is it trending?

Instatic comes from CoreBunch, the team behind Motion.page and Core Framework, two tools with a large following among people who build WordPress sites for a living. That lineage explains the design side. Core Framework is not a plugin here, it is wired in as a core system: define one brand color and the tool generates the tuned tints and shades, define one type ramp and it scales fluidly instead of leaving you forty hand-picked font sizes to keep in sync.

RelatedOpenCut Setup: Self-Host the Free CapCut Alternative

The editor is a genuine canvas rather than a form with a preview pane bolted to the side. You can place several breakpoint frames next to each other and edit them together, so a desktop change updates the mobile frame in the same view. Reusable pieces, called Visual Components, take typed parameters and named slots. There is also an AI agent that edits the canvas as real nodes rather than dumping a screenshot or a wall of code, with a 35-tool scope for building pages and a 15-tool scope for editing entries. It is bring-your-own-key: Claude, OpenAI, OpenRouter or a local Ollama, and your bill.

The trending spike is mostly about who it threatens. Webflow and Framer are excellent and rented. WordPress is yours and carries thirty years of markup you are not allowed to touch. Instatic is a third answer, and the pitch that gets it starred is that the published output has none of the editor's machinery in it.

How do you run Instatic locally?

You need Bun. That is the whole prerequisite list. The default dev setup runs on SQLite, so there is no database service to stand up first, and the same four commands work on macOS, Linux and Windows:

# local dev on SQLite, no other services needed
git clone https://github.com/corebunch/instatic.git
cd instatic
bun install
bun run dev

Open http://localhost:5173 and the first visit walks you through creating the site and your owner account. That runs the admin through Vite in dev mode. To see it the way it actually ships, build the admin and serve it from the Bun server instead:

# production-shaped: admin served from the Bun server
bun run start

That puts the admin at http://localhost:3001/admin. Worth doing before you judge performance, because dev mode is not what your visitors get.

How do you self-host it on a VPS?

Production is a single Docker image, ghcr.io/corebunch/instatic, driven by compose files that ship in the repo and in the release bundle. Before you start the stack, set a secret key. Instatic needs it to encrypt reversible server secrets: AI provider credentials, plugin secret settings and TOTP seeds. Skip this and two-factor auth and stored AI keys will not work properly:

# generate and paste INSTATIC_SECRET_KEY into .env
cp .env.production.example .env
bun run scripts/generate-secret-key.ts

Then bring up the SQLite stack against the published image. One app container, two persistent volumes:

$ INSTATIC_IMAGE=ghcr.io/corebunch/instatic:latest docker compose -f compose.prod.yml -f compose.sqlite.yml up -d

The data volume mounts at /app/data and holds the SQLite database; uploads mounts at /app/uploads and holds media, fonts, plugins and published artefacts. Open http://server-ip:3001/admin to create the site. Want HTTPS handled for you? The docs ship a Caddy layer, and building from source with TLS is one longer command:

# source build, SQLite, Caddy TLS on ports 80 and 443
docker compose -f compose.prod.yml -f compose.sqlite.yml -f compose.tls.yml -f compose.build.yml up -d --build

Point the domain's A record at the server first. If you would rather have multiple simultaneous admin writers or managed database backups, drop compose.sqlite.yml to get the Postgres service, set a real POSTGRES_PASSWORD in .env, and generate it properly:

$ openssl rand -hex 24

There is also a Railway one-click template for both SQLite and Postgres, which generates the secret keys, attaches the storage volume and sets up health checks without you opening a terminal. Updating later is a redeploy of the newer image, because the database and uploads live on the attached volume rather than inside the container.

RelatedOmniRoute Setup: One Endpoint for 290 AI Providers

How does it compare with Webflow, Framer and WordPress?

That last row is doing a lot of work, and the plugin row is the one developers should read twice. A WordPress plugin runs as PHP with the same privileges as the site. An Instatic backend plugin runs in a per-plugin worker hosting a QuickJS-WASM sandbox with no filesystem, no environment variables and no network at all unless the owner grants it, one host at a time. That is a meaningfully different security posture for the single most common way a CMS gets compromised.

What are the gotchas before you rely on it?

Five, and the first one is not subtle. This is version 0.0.13, released July 24, with 0.0.14 already in development. The maintainers say plainly that APIs and workflows can shift before 1.0, and they are right to. Do not put a client's revenue site on it this quarter unless you enjoy migrations.

Second, the Bun requirement is pinned narrowly. The package manifest declares "bun": ">=1.3.0 <1.4.0", so a machine running a newer Bun will need a pinned install rather than whatever bun upgrade last handed you. Third, the sandbox story has an exception worth knowing: editor extensions and app-kind admin pages run in the admin window, not in QuickJS, and require an explicit editor.code permission at install time. Grant that only to plugins you would trust with your session.

Fourth, the Analyze pillar is thinner than the marketing pillar list implies. What exists today is a dashboard of tile widgets, an append-only audit log, and form submissions in your own tables. First-party visitor analytics is on the roadmap, not in the box, so plan on a separate analytics choice. Fifth, backups are simple but they are yours: dump the Postgres database or copy the SQLite file, copy the uploads folder, done. Nobody is doing it for you, and there is no vendor support line when a disk fills.

Our take

The interesting bet here is not the visual editor, which plenty of tools do well. It is that publishing should end with a file on disk rather than a render, and that the editor should leave no trace in what it produces. Everything else follows from that: no framework runtime on the public page, no builder attributes in the markup, a 1.1 kB script only where a page truly needs one, and nothing holding the site hostage if you decide to leave. A team that spent years making WordPress bearable clearly knew exactly which compromise they were tired of.

What I would not do is confuse a strong architecture with a finished product. Version 0.0.13 is the maintainers telling you the truth, and the right move is to run it on something you would not cry over: a personal site, an internal docs site, a landing page you can rebuild in an afternoon. If it survives a few of your own redeploys, revisit it when 1.0 lands. Fifteen minutes with Bun is a cheap way to find out whether the output really is as clean as the README claims, and that is a claim you can verify yourself with view-source.

Original analysis by GenZTech. Tool documentation: CoreBunch/Instatic on GitHub.