Stand up your live Seedly Sites instance - Railway for the CMS and database, Cloudflare Pages and R2 for hosting and media, GitHub for deploys.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
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.
| Piece | Where It Runs | What It Does |
|---|---|---|
| CMS service | Railway | Your admin, the portal, the API. The thing you log into |
| Postgres | Railway | The production database (replaces the local sandbox's file database) |
| Studio (pagebuilder) service | Railway | Serves the visual builder and page preview; the CMS proxies to it so the builder is same-origin |
| Pages projects | Cloudflare Pages | Static hosting - one project per client site |
| R2 bucket | Cloudflare | Durable storage for uploaded media |
| Private repo + deploy workflow | GitHub | Your copy of the code, plus the automated job that builds and deploys a client site when you click Deploy |
See Architecture for how the pieces talk to each other.
Work through these in order. Each step is one provider account plus a few values you copy into the platform's environment settings.
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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
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.
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.
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:
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.
Once the doctor says READY:
SUPER_ADMIN_EMAIL, or the Users item will not appear in your dashboard.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.