Provisioning & Going Live

The local sandbox from the Install guide proves everything works. Going live moves the same platform onto real infrastructure so client sites are on the internet with their own domains.

Your SETUP/ handbook covers this in detail (chapters 04 through 13, with click-by-click steps for each provider). This page is the map: what you are creating, where, and how to verify it.

What a Live Instance Looks Like#

See Architecture for how the pieces talk to each other.

The Provisioning Steps#

Work through these in order. Each step is one provider account plus a few values you copy into the platform's environment settings.

1. Put your code in a private GitHub repo#

Your download becomes a private repository you own. The deploy pipeline (a GitHub Action in that repo) is what builds and publishes client sites. You will create a personal access token so the platform can trigger that workflow, and point the platform at your repo. Set your OWN repo here - the readiness check flags this value if it is still the vendor default.

2. Create the Railway project#

Three services: the cms app, a Postgres database, and the pagebuilder studio. Point the cms service at Postgres and switch it to the production database adapter, then wire the CMS to the studio via its internal URL so the builder loads in production.

3. Create the Cloudflare pieces#

An R2 bucket for media (with access keys and a public URL for serving files), and an API token that lets the platform auto-create a Pages project per client site. You also add these as GitHub Actions secrets so the deploy workflow can push builds to Pages.

4. Generate and set your secrets#

npx pnpm run gen:secrets

generates the platform's own secret values (session signing, cron auth, and the rest). Put app-owned secrets and config on the Railway cms service; put the deploy credentials in GitHub Actions secrets. Then check your live values on the Setup page at /operator/setup on your live CMS, or run railway run -s cms -- node scripts/setup/setup-check.mjs --target=prod from your project folder once the Railway CLI is linked. A plain local setup:check grades your local sandbox, not your live setup. Neither check can see your GitHub Actions secrets, so check those in your repo's settings. Keep a copy of everything in a password manager - see Backups.

5. Set up email#

Password resets and client intake links send through SendGrid, and your CMS also uses it to email you when a scheduled job fails. Create a restricted API key with mail-send permission, verify your sending domain, and set the key and From address on the cms service. The go-live check treats both as required. Until they are set the platform runs, but nothing is delivered: an intake link is shown in the dashboard for you to copy by hand, and a password-reset link is lost, because the platform never writes it to its logs. A new SendGrid account is a trial, and sending pauses when it ends unless you have picked a paid plan. Nothing inside the platform warns you when that happens.

6. Point DNS#

Your CMS gets a hostname: Railway gives you a CNAME and a TXT record to add at your registrar, and it needs both before the domain verifies. If Cloudflare runs that domain's DNS, leave the CNAME proxied and set SSL/TLS to Full. Each client site's custom domain points at its Cloudflare Pages project and is also recorded on the tenant; for a site that already exists, that field is in /admin (Tenants), not the portal. See Hosting & Domains.

7. The Anthropic key, then optional keys#

The Anthropic API key powers AI site generation, port revision, and visual QA. The go-live check treats it as required, and it goes in two places: the cms service and your GitHub repo's Actions secrets.

The rest are optional:

• Stripe keys - only if you want native tenant billing
• Google Places / Maps embed keys - richer location capture and map cards
• Sentry DSN - error monitoring
• Zembra API token - connected review widgets that keep a client's reviews up to date. Optional and paid: Zembra is a separate company you fund yourself, and each connected listing is charged again every 30 days until you disconnect it. Read chapter 10 of your handbook before you set a token. Reviews typed in by hand cost nothing and need no account

Everything optional fails soft: the platform runs, the feature is simply inert until the key exists.

The setup preflight checks for the Anthropic key and tells you it is missing before you start a generate, rather than letting a build begin and fail partway. If you intend to use AI generation at all, set it during provisioning.

8. Hand the scheduled jobs to your CMS#

Your repo ships a few scheduled jobs (publishing posts you scheduled, the automatic backup, and routine clean-up sweeps). They start on GitHub as soon as your code is pushed, and every run spends minutes from your GitHub Actions allowance. Your CMS runs the same jobs itself at no cost. Once email is set up, run this from your project folder with the Railway CLI linked:

npx pnpm run setup:scheduler

It checks that your CMS really is running the jobs and has it send you a test email, then switches GitHub's timers off, or, if the GitHub CLI is not signed in, prints the one browser step that does it. After that, a single watchdog on GitHub tells you if the CMS ever stops running them. Keep Railway's App Sleeping setting off on the cms service, and keep it at one replica: a sleeping CMS runs no jobs, and each extra replica runs them again.

A Railway Setting to Watch#

If your Railway service has a Custom Start Command filled in, it overrides the project's own start script. A value left over from an earlier setup will quietly skip the real startup path, and the symptom (a service that comes up but behaves oddly) does not point at the cause. Leave it empty unless you know you need it.

Your Own Password#

Provisioning uses the password you type for the local login, so the credentials you set are the credentials that work. If a first sign-in is rejected, you are probably on the wrong instance rather than the wrong password.

The Doctor#

At any point, open /operator/setup on your live CMS. It runs inside your real production environment and gives a Go-live ready verdict. From the project folder, with the Railway CLI linked, the command-line version is:

railway run -s cms -- node scripts/setup/setup-check.mjs --target=prod

A plain local npx pnpm run setup:check grades your local sandbox, not your live setup.

It prints READY or NOT READY and names each missing or misconfigured value in plain English. Work top-down through the red lines; set each value on the correct service and redeploy. This is also the first thing to run when anything feels off later.

The guided alternative for a fresh instance is npx pnpm run provision, which walks the whole sequence. Provisioning is fresh-instance only: it refuses to run against an already-live setup, on purpose.

First Login and First Site#

Once the doctor says READY:

1. Create your operator (super-admin) account and log in to your live CMS. Do this as soon as the cms service boots: until the first account exists, the create-first-user screen is open to anyone who finds the address. Use the same email you set as SUPER_ADMIN_EMAIL, or the Users item will not appear in your dashboard.
2. Create your first client site in the portal (Managing Sites).
3. Build or port its pages, publish, and click Deploy.
4. Confirm the deployed site loads on its Pages URL, then attach the custom domain.

Remember the platform rule: publishing content never deploys anything by itself. The site goes live, and gets updated, only when you deploy it. See Preview, Publish, Deploy.

After Launch#

• Enable Postgres backups on Railway and do one restore drill early (Backups)
• Read Updating before your first version update
• Keep the leaked-key rule: if a secret ever ends up somewhere it should not, rotate it at the provider and update it everywhere it is stored