Deployment Procedures
Updated: Wed 06 May 2026 17:14:18 CEST — Phase 1 naming migration: removed Lovable Cloud / lovable.space references; restructured by service
This guide covers building and shipping each Plings service to production. All services deploy to Vercel from their respective repositories.
Plings-Web
- Source:
Plings-Web/(folder rename pending Phase 2) - Live URL:
https://plings.io - Vercel runtime: Static CDN (Vite build output)
Preview / branch builds
Vercel automatically creates a preview deployment for every push to a non-main branch. The preview URL is posted as a GitHub comment on PRs.
Production
- Merge PR into
main - Vercel runs
npm run build(vite build) and publishes thedist/output toplings.io - Smoke-test (see Smoke Tests below) before announcing
Rollback
In the Vercel dashboard for the project: Deployments → pick a previous successful deployment → Promote to Production.
Plings-Gateway
- Source:
Plings-Gateway/ - Live URL:
https://s.plings.io - Vercel runtime: Edge
Production
Same flow as Plings-Web — push to main, Vercel auto-deploys. The Edge runtime requires the bundle to stay small; check the Vercel build log for size warnings.
Rollback
Promote a previous deployment in the Vercel dashboard, same as Plings-Web.
Plings-API
- Source:
Plings-API/ - Live URL:
https://api.plings.io - Vercel runtime: Serverless Functions (Python)
Production
- Merge PR into
main - Vercel installs from
requirements.txtand deploys the FastAPI app - Confirm GraphQL endpoint at
https://api.plings.io/graphql
⚠ Critical: keep requirements.txt in sync
Vercel deploys from requirements.txt, not from pyproject.toml. When adding or removing Python dependencies during local Poetry development, regenerate requirements.txt before merging:
poetry export -f requirements.txt --output requirements.txt --without-hashes
If you skip this, the deploy will succeed but the runtime will fail on missing imports.
Rollback
Promote a previous deployment in the Vercel dashboard.
Smoke Tests
After any production deploy, verify these endpoints:
| Service | Test |
|---|---|
| Plings-API | curl https://api.plings.io/graphql returns the GraphiQL interface or a 200 introspection response |
| Plings-Gateway | curl -I "https://s.plings.io/?t=q&i=test&p=1.1.1.1.1" returns a 3xx redirect |
| Plings-Web | https://plings.io loads and login works |
Cross-service deploy order
When a change touches multiple services:
- Schema-additive backend changes first — deploy Plings-API first if it adds new GraphQL fields or types; existing clients keep working
- Schema-breaking backend changes — deploy clients first with feature flags off, then API, then enable flags
- Gateway-only changes — deploy independently; the API and Web don’t depend on Gateway’s behaviour