Deploy to Render

What the blueprint makes#

Pick a region for the web service and database close to the workflow if you change it. Plans can be raised later in the dashboard; check Render's pricing page for what each costs.

Step by step#

1. Fork or push the repo to your own GitHub (or GitLab) account.
2. In Render, choose New, then Blueprint, and pick the repo. Render reads render.yaml and lists the four resources.
3. Fill in the values marked sync: false. You can leave any optional service blank and add it later; see Environment variables for what each does. At minimum: NEXT_PUBLIC_ROOT_DOMAIN and BETTER_AUTH_URL on the web service and the workflow, and RESEND_API_KEY + EMAIL_FROM so people can sign in.
4. On the cron job, set RENDER_API_KEY to an API key from your Render account settings. RENDER_WORKFLOW_SLUG is filled in from the workflow for you.
5. Apply. BETTER_AUTH_SECRET and CRON_SECRET are generated, and the secret is copied to the workflow.

Domains

1. On the web service, add two custom domains: resell.store and *.resell.store (your own domain, if different). The wildcard covers every store and the api., docs. and mcp. hosts.
2. Add the DNS records Render shows for each. Copy the exact targets from the dashboard, and remove any AAAA records: Render doesn't support IPv6 for custom domains.
3. Set NEXT_PUBLIC_ROOT_DOMAIN=resell.store and BETTER_AUTH_URL=https://resell.store on the web service, and the same on the workflow. The root domain is baked in at build time, so trigger a new deploy after changing it.

On Cloudflare, use a CNAME on @ instead of the A record, and keep every record on DNS only (grey cloud) until Render has verified the domains and issued certificates. If you turn the proxy on afterwards, set SSL/TLS to Full. The wildcard only works while the root domain also points to Render.

Outside services

• Resend: verify your domain in Resend and set EMAIL_FROM to an address on it, on both the web service and the workflow (the workflow sends reminders and payout emails).
• Cloudflare R2: create a bucket (default name resell-store) and an API token with read and write on it. Set R2_URL to https://{account_id}.r2.cloudflarestorage.com plus the two keys. For speed, connect a custom domain to the bucket (like files.resell.store) and set R2_PUBLIC_URL; the r2.dev address is rate-limited.
• PayPal: set the client id (also as NEXT_PUBLIC_PAYPAL_CLIENT_ID), secret, partner merchant id and BN code, on the web service and the workflow. Then, in the developer dashboard under your app's Webhooks, add https://resell.store/api/paypal/webhook with these events, and paste its id into PAYPAL_WEBHOOK_ID:

PAYMENT.CAPTURE.COMPLETED
PAYMENT.CAPTURE.DENIED
PAYMENT.CAPTURE.DECLINED
PAYMENT.CAPTURE.REFUNDED
PAYMENT.CAPTURE.REVERSED
CUSTOMER.DISPUTE.CREATED
CUSTOMER.DISPUTE.UPDATED
CUSTOMER.DISPUTE.RESOLVED
MERCHANT.ONBOARDING.COMPLETED
MERCHANT.PARTNER-CONSENT.REVOKED
PAYMENT.REFERENCED-PAYOUT-ITEM.COMPLETED
PAYMENT.REFERENCED-PAYOUT-ITEM.FAILED

• The demo seller (sandbox): from your machine with the same PayPal keys, run node --env-file=.env.local scripts/paypal-demo-seller.mjs in apps/app, follow the link it prints, run it again, and set the printed PAYPAL_DEMO_SELLER_ID on the web service and the workflow. Add the demo seller and buyer logins (PAYPAL_DEMO_*_EMAIL / _PASSWORD) to the web service if you want them shown in the app.
• The rest are just keys: ANTHROPIC_API_KEY, CHANNEL3_API_KEY, KERNEL_API_KEY, JINA_EMBEDDING_MODEL_KEY, and SUPPORT_EMAIL for escalations.

What happens on each deploy#

1. Build: corepack pnpm install --frozen-lockfile && corepack pnpm --filter app build. pnpm runs through corepack because corepack enable can't write to Render's read-only /usr/bin. The NEXT_PUBLIC_ values are baked in here.
2. Pre-deploy: cd packages/db && npm run db:migrate applies any new migrations. If it fails, the deploy stops and the old version keeps serving.
3. Start: cd apps/app && npm start. Render switches traffic once the health check on / passes.

The workflow and cron job install dependencies and run from source with tsx; they have no build step and no migrations of their own.

Seeding a deployed database#

To fill a fresh deploy with the ten demo stores, run the seed from your machine against the database's External Database URL (on the database's page in Render). It refuses a remote database unless you say --remote. Render only accepts encrypted connections from outside, which PGSSLMODE=require turns on:

cd apps/app
PGSSLMODE=require DATABASE_URL="postgres://resell:...@....render.com/resell" pnpm seed --remote

It uses the rest of your local .env.local: with R2 keys set there, the photos go to that bucket (use the same one as production); without, they go into Postgres. With a Jina key, the listings get embeddings. Running it again replaces only the seed's own rows.

Check it works#

• https://resell.store loads, and https://docs.resell.store shows these docs.
• https://api.resell.store/v1/openapi.json returns the API description.
• A store loads on its subdomain, e.g. one from the seed.
• Signing in by email works: the link arrives, and you stay signed in when you open your store.
• A checkout with the sandbox buyer completes, and the order shows on both sides.
• The cron job's log shows Started resell-sweeps/offerSweep: … every 15 minutes, and the workflow's runs succeed.
• In the PayPal dashboard, webhook deliveries to your site come back 200.

Troubleshooting#

More on the timed side in Background jobs.