Take Seedly Communities live on your own Convex and Vercel accounts, connect the two halves, promote environments safely, and run the go-live checklist.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Going live is the same shape as the local run, moved onto real infrastructure that you own. The backend deploys to Convex Cloud and the web app deploys to Vercel. Both accounts are yours, both bills are yours, and your data never sits on a Seedly server. That is what "deployed on infrastructure you control" means for this product.
Deploy the backend first, then the web app, then connect them. Work through the go-live checklist at the end before you invite a single real member.
You are not renting a seat on a hosted community product. You own the source, and you run it on two accounts you create and pay for directly.
Because both accounts are yours, you set the plan, you hold the keys, and you decide when anything changes. Seedly ships the code once and takes no ongoing cut.
Keep at least two environments so you never test on the same backend your members use.
A staging environment (a third deployment that mirrors production) is worth adding once you have members, so you can rehearse updates before they reach anyone.
From the project folder, push the backend to a production Convex deployment.
This creates or updates your production backend on Convex Cloud and prints its production URL. That URL is what the live web app talks to, so keep it handy for the next step.
Your backend also needs its own configuration values set on the production deployment, not just in your local file. Set each backend secret and setting on the Convex production deployment with the environment command.
Use the names on the Environment and Configuration page. Keep production values separate from local development values, and confirm the target deployment before setting each one. This keeps a local test from changing the live configuration.
Connect your project to Vercel, either by importing the Git repository in the Vercel dashboard or with the Vercel command line tool.
During setup, Vercel asks for the project's environment values. Add every web-app setting from the Environment and Configuration page to the Vercel project, including the production backend URL from Step 1. Set them on the Production environment (Vercel also has Preview and Development scopes, which are handy for a staging build).
When the values are in place, ship the production build.
Vercel builds the web app and gives you a live URL.
The web app finds the backend through the backend-URL setting, and the backend trusts the web app through its app-URL setting. Both must point at the production counterpart.
Redeploy whichever half you changed so the new values take effect. Open the live URL and confirm the feed, classroom, chat, and events all load against the production backend.
Promote changes in one direction, from development toward production, and never edit production data by hand to work around a code change.
npx convex deploy.npx vercel --prod.Keep backend and web app in step. A web app build that expects new backend behavior should go out after the backend push, not before. When in doubt, deploy the backend, confirm it is healthy, then deploy the web app.
Work through this before real members arrive. The production doctor checks most of it for you.
npx convex deploy has run and the production URL is recorded.AUTH_PROXY_SECRET is set on Vercel and the website redeployed first, and only then set to the same value on the production backend. The reverse order refuses every sign-in until the website redeploy finishes.npx pnpm run provision) and no demo seed data was ever run against production.Next, connect payments, then email, then live video. New to the platform? Start with Getting Started.