Deploy Aphex Website (SQLite + Volume)

Deploy and Host Aphex CMS on Railway

Aphex CMS is an open-source, developer-first content management system built on SvelteKit. Unlike headless CMSes it is embedded: the same app that serves your website also runs the editing studio, so there is no separate backend to deploy and no content API to wire up. This template deploys a complete, editable website — a block-based page builder, a blog, full-text search and visual editing — as a single service backed by SQLite on a persistent volume.

One container, one volume, nothing else. No database service, no object storage, nothing to configure.

About Hosting Aphex CMS

Hosting Aphex means running one SvelteKit container. It serves the public site, the /admin studio, a REST and GraphQL API, and an MCP endpoint from the same process.

This template keeps the whole site's state on one volume mounted at /data — the SQLite database file and the uploaded media both live there. That is what makes it a single service, and it is the one part that cannot be recreated: the volume is your site. SQLite runs in WAL mode with a busy timeout, which is what makes it a real choice for a web workload rather than a toy one — readers never block the writer.

The schema is provisioned at startup, so there is no migration step to run and nothing to manage as your content model changes. The background job queue — scheduled publishing, event consumers — runs in-process, so no worker service or cron is required.

Uploaded media is never served from disk directly. Every asset is addressed through the app at /media/:id/:filename, which is what lets private files stay private and resized variants be generated on demand and cached permanently.

This template is meant to become your website. Deploy it to see how it works, build your own version locally with pnpm create aphex, then point this same project at your repository — your content, uploads and domain stay exactly where they are.

Why Deploy Aphex CMS on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Aphex CMS on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Specifically for Aphex, Railway supplies the two things this template can't bring with it: a persistent volume, so the database and uploads survive every redeploy, and a public domain, which the container reads at startup to derive its own auth origin — so sign-in works on the first boot with no URL to configure. Railway's volume backup schedule covers the database and the media in one go, because both live on the same volume.

Common Use Cases

• Marketing and company websites — a block-based page builder with reusable layout blocks and four hero treatments, editable by non-developers without touching code.
• Blogs and publications — dated articles with rich text, inline media and code blocks, categories, related posts, a paginated archive and full-text search.
• Client sites built by agencies — define the content model in TypeScript, hand over a studio with roles, invitations and per-field access control, and let the client edit visually on the live page.
• Small-team sites that should stay cheap and simple — one service, one volume, no managed database to pay for or tune.

Dependencies for Aphex CMS Hosting

• A persistent volume mounted at /data — holds the SQLite database and uploaded media. This is the only dependency, and the template provisions it.

Deployment Dependencies

• Aphex CMS documentation
• Railway deployment guide
• Source repository
• Resend — optional, required for password reset, email verification and team invitations.

Implementation Details

First steps after deploying

1. Go to /login and create your account immediately. The first account to sign up becomes super admin. On a public URL that is a race, so either set APHEX_BOOTSTRAP_EMAIL before deploying or claim the instance as soon as it is live.
2. Open /admin. Your organization and roles are created for you on first sign-in.
3. Example content — real articles, images and navigation — is created on the first boot, so every block and page has something in it. Set APHEX_SEED=false to start empty.
4. Edit Site Settings, Header and Footer to make it yours.
5. Switch the app to your own repository — this template is meant to become your site, not to be built on in place. See below.

This is meant to become your website

The deployed site is a starting point, not a demo you build something else next to. The intended path is: deploy it to see how it works, build your own version locally, then point this same project at your repository. You keep the volume, the content and the URL — only the code changes hands.

1. Build it locally.

pnpm create aphex my-site   # choose the website template
cd my-site && pnpm dev

The same app, running on a local SQLite file, with nothing to install. Edit the content model in src/lib/schemaTypes/, the blocks in src/lib/blocks/, and the front end in src/routes/(site)/. Delete the example schemas and seed once your own model exists — nothing else depends on them.

Use pnpm create aphex rather than forking this repository: you get a clean git history and the current template, instead of a mirror you will never merge from.

2. Push it to your own GitHub repository.

3. Switch this project over to it. Open the app service → Settings → Source and connect your repository in place of this one. Railway rebuilds from yours on the next deploy.

What carries over: everything except the code. The volume is attached to the service, not the repository, so your pages, posts, users, uploads and domain all stay exactly as they are. Schema changes are applied on the next boot.

Do this before you rely on the site. Until you switch, the app service is connected to this repository — so it redeploys whenever the template is updated, and your site would change on our release schedule rather than yours. Fine while you are evaluating; not something to leave in place.

Optional environment variables

Things that will bite you

• The volume must exist before the first deploy. Adding it later mounts it empty over /data, so a database and uploads written to the container filesystem are gone rather than migrated. The template provisions it — just don't detach it.
• Turn on the volume's backup schedule. It is the only copy of your site. SQLite in WAL mode keeps three files (website.db, -wal, -shm), and a volume-level backup catches all three where copying the .db alone silently loses the un-checkpointed tail.
• Size the volume for your media. The database and the uploads share it, so a large media library eventually fills the same disk the database writes to — and a full disk stops SQLite accepting writes, which makes the whole CMS read-only. Watch it, or move media to object storage (set S3_ENDPOINT, S3_BUCKET, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY and drop APHEX_UPLOADS_DIR) before that becomes real. Do it before the first upload — switching later does not move files already on the volume.
• One instance only. A volume attaches to a single container, so this template cannot scale horizontally and deploys are a brief stop-then-start rather than zero-downtime. That is the trade for a single service. Move to PostgreSQL and object storage when it matters.
• AUTH_SECRET and APHEX_SECRET_ENCRYPTION_KEY must stay stable. Rotating the first signs everyone out and invalidates every API key; rotating the second makes stored plugin secrets permanently unreadable.
• Without email configured, a lost password is unrecoverable. The account you sign up with is the only way in.

Prefer to start locally? pnpm create aphex scaffolds the same template on your machine, no infrastructure required.