Common Seedly Sites problems and their fixes - install, live setup, deploys, domains, email, AI features, billing, and updates.
Loading the guide...
Did this answer your question?
Help us make the guides more useful.
0 helpful · 0 not helpful
Common Seedly Sites problems and their fixes - install, live setup, deploys, domains, email, AI features, billing, and updates.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Common problems and their fixes, grouped by what you were doing. If you do not see your issue, run the doctor (npx pnpm run setup:check) - it names what is wrong in plain English - then ask in the Seedly Community on Facebook.
Jump to where the problem happened: local setup, live platform setup, client site deploy, scheduled jobs, email, AI features, billing, or updating.
Either the tool is not installed yet (Install guide) or your terminal window predates the install. Close the terminal, open a new one, and try again. For pnpm, always use npx pnpm.
You need the Node 22.x line. Node 20 and older are too old. Node 24 and newer run the local sandbox but are not supported, and every pnpm command prints an "Unsupported engine" warning on them. Install 22 from the releases list on nodejs.org and re-check.
Retry on a stable connection. If it fails with a permissions error, close and reopen the terminal and try once more.
PowerShell blocks scripts by default, and npx is one. Either open Command Prompt instead of PowerShell and run the same commands there, or allow scripts once by running Set-ExecutionPolicy -Scope CurrentUser RemoteSigned in PowerShell and answering Y.
Some of the project's pieces come in a separate version for each kind of computer, and the one for yours did not get installed, usually because an earlier install was interrupted. Run npx pnpm install --force, then your command again. If it still fails on Windows, check Windows Defender's Protection history in case it removed the file.
The GitHub CLI is not installed yet: winget install GitHub.cli on Windows, brew install gh on a Mac (see the Install guide). Then close the terminal, open a new one, go back to your project folder, and carry on.
Set your git name and email once per computer, with your own details, then run the commit again: git config --global user.name "Your Name" and git config --global user.email "you@example.com".
Give both servers a moment to finish starting. The CMS is on port 3000 and the studio on 4321. If something else already uses one of those ports, npx pnpm m6:dev stops straight away and names the busy port. Close the other program (often an earlier sandbox in another terminal window) and start again, or move the sandbox with SEEDLY_CMS_PORT and SEEDLY_STUDIO_PORT, for example SEEDLY_CMS_PORT=3100 SEEDLY_STUDIO_PORT=4400 npx pnpm m6:dev on a Mac. If you move a port, change RENDER_BASE_URL in packages/cms/.env.local and PAYLOAD_API_URL in packages/render/.env to match.
The CMS does not know the studio's address. Add the line RENDER_BASE_URL=http://localhost:4321 to packages/cms/.env.local and restart the dev servers. Add to the file, never replace it: if setup created it, it also holds your sandbox login and secrets. Step 3 of the Install guide has the exact command for Mac and Windows.
The preview server has no login of its own, so it cannot read your content. In the local sandbox, create packages/render/.env containing PAYLOAD_API_URL=http://localhost:3000, PAYLOAD_EMAIL= your admin email and PAYLOAD_PASSWORD= your admin password, one per line, then restart the dev servers. On a live instance use a PAYLOAD_API_KEY instead (minted on /admin/account in your CMS), set on the pagebuilder service.
A user already exists in that database. Log in with the email you expect. In the local sandbox you can also start over: stop the servers, delete packages/cms/database.sqlite, and start them again, and the first-user screen comes back. Never delete anything on a live instance.
The resume command lost the part after the colon, usually because the line was cut off when it was copied (a narrow terminal window wraps long lines). Type or paste the whole line, with the quotes, exactly as the setup prints it, for example node scripts/setup/provision.mjs "--from=prod:railway-link". A short intro and a tool check always run first; that is normal. From version 2.0.5 the setup prints the step it is picking up at before anything else, and refuses a command that stops at the colon instead of starting over.
Your repo was already created on an earlier run. From version 2.0.5 the setup notices and moves on. On 2.0.4, answer n when it offers to run gh repo create, then y when it asks whether the step is done, or resume at the next step with node scripts/setup/provision.mjs "--from=prod:railway-create".
There is no project for it to link to yet. Create the Railway project in your browser first (cms, pagebuilder and Postgres), then link again. If the project does exist, check that railway whoami shows the account you use on railway.com, and link it directly with the id from the address bar: railway link --project <id> --environment production.
The three services must be named exactly cms, pagebuilder and Postgres. "Page Builder" does not work, because other settings find each service by that name. If you clicked Deploy while Railway still showed extra tiles (core, builder, render, cli), delete them: click the tile, Settings, scroll to the bottom, Delete Service.
R2 is not switched on for your Cloudflare account yet. Open the Cloudflare dashboard, click R2 (under Storage & databases), and complete the checkout. It asks for a card even though R2 has a free allowance. Then run the bucket step again.
The database tables were never created. On the cms service, open Settings and make sure Custom Start Command, Custom Build Command and Watch Paths are all empty (Railway fills them in when it reads your repo), then redeploy. To create the tables straight away, open the cms service's Console tab on railway.com and run pnpm --filter @seedly-sites/cms migrate. It uses the database your cms service already has. Then reload /admin.
Check the database connection value is the Railway Postgres connection string and the production database adapter is selected on the cms service. Then read the service's deploy logs for the first error.
Almost always the CMS-to-studio wiring: on the cms service, confirm the studio internal URL matches your pagebuilder service's internal domain and port, then redeploy. See Provisioning.
First make sure the check read your live environment: open /operator/setup on your live CMS, or run railway run -s cms -- node scripts/setup/setup-check.mjs --target=prod from your project folder. A plain local setup:check grades your local sandbox, even with --target=prod. Then work top-down through the red lines; each names the exact variable or check. Set it on the correct Railway service and redeploy.
Set your own value for that variable - most often the super-admin email, the deploy repo, or the platform secret.
You set the value on your machine but not on the Railway service. Set it on the service and redeploy.
Open the failed run and read the name of the step that went red. Preflight - required repo secrets means a GitHub Actions secret is missing, and the log names each one. Content-readiness gate has two different causes. A 403, CMS auth failed or pages fetch failed is a problem with the build's CMS login (check the PAYLOAD_API_URL and PAYLOAD_API_KEY, or PAYLOAD_EMAIL and PAYLOAD_PASSWORD, secrets). A list of pages with reason codes ending in Deploy BLOCKED is a content problem on a published page: fix it in the builder, publish the page, and deploy again. Blocks you have switched off in the builder are not checked. Ensure Pages project exists points at CF_API_TOKEN or CF_ACCOUNT_ID.
Check the public media URL is set correctly and the R2 bucket has a working public URL. Then redeploy the site.
The domain must be added in two places: on the tenant's Cloudflare Pages project AND as the tenant's custom domain, with the DNS record set at your registrar. For a site that already exists, set the custom domain in /admin (Tenants, open the client, Custom domain in the right-hand sidebar); the operator portal offers the field only when you create a site. A bare domain (no www) needs Cloudflare to run its DNS first. See Hosting & Domains.
The redirect takes effect on the NEXT deploy after you set the custom domain. Deploy the site again.
The build's status callback was lost, so the result never came back. Once enough time has passed that the build cannot plausibly still be running, the Deploy button frees up on its own and you can retry. You do not need to touch the database.
If the machine doing the work was killed partway, the job is swept and marked failed rather than showing as running forever. A failed setup points you at its recovery path. Retry from the board.
An empty template library is not the cause: with no template seeded the picker says so and the form still submits. Seed a pack so clients have a look to choose; see Install.
setup:scheduler says "Not moving the jobs yet"SendGrid is not set up on the cms service yet, so your CMS would have no way to email you when a job fails. Nothing was changed. Set up email, redeploy the cms service, and run npx pnpm run setup:scheduler again.
setup:scheduler ends with "One step left, in your browser"It could not set the GitHub repository variable itself. Follow the three steps it prints; they add a repository variable named SCHEDULED_TASKS_RUNNER with the value cms. Until that variable exists, GitHub and your CMS both run the jobs.
Your CMS has stopped running the scheduled jobs, or did not answer, and the run's message says which. Check the cms service on Railway: a sleeping or stopped service runs no jobs, and its logs show lines beginning [scheduler]. To hand the jobs back to GitHub in the meantime, delete the SCHEDULED_TASKS_RUNNER repository variable.
Confirm your sending domain is verified with your email provider, then check its activity log for a bounce or block. Confirm the email key and From address are set on the cms service and that it redeployed.
A new SendGrid account is a trial, and sending pauses when it ends unless you have picked a paid plan. Nothing in the platform reports it: the key is still set, so the go-live check stays green while password resets and client intake links stop arriving. Check the plan and billing pages in SendGrid.
Re-check the Anthropic API key on the cms service and confirm the service redeployed after you set it.
The webhook signing secret does not match the endpoint, or the webhook URL is wrong. Re-copy both from Stripe and try again. See Billing.
Your cms service runs its migrations every time it starts, so first check that its Custom Start Command (Settings > Deploy on Railway) is empty. A value there replaces the start step that runs the migrations, so they are skipped on every deploy. Clear it and redeploy. If a migration itself failed, the cms deploy is red and its log has a line beginning [migrate] FAILED:; see Updating.
On a site built before 2.0.0, some headings from the template packs carried a fixed near-black colour that had no effect until 2.0.0 made the heading Color control work on the published page. Those headings paint near-black from the site's next deploy, which can be hard to read on a dark band. Open the heading in the builder and set Color to None to hand it back to the brand colour. Sites built from the packs in 2.0.0 or later are not affected.
Since 2.0.0, elements inside your header and footer get their own ID prefix. If you hand-wrote a link that jumps to an element inside the header or footer by its ID, a custom CSS rule in Site Settings that targets one, or a script that looks one up by ID, re-point it after you next deploy. Links and rules aimed at the page body, and the skip-to-content link, are unaffected. The built-in header's mobile navigation toggle is now hc-tpl-nav-toggle rather than tpl-nav-toggle.
provision again on an already-live instance.