2. Deploying to Production

Your app is working locally. This tutorial walks through going live: understanding the pre-configured deployment pipeline, updating your app URL config, configuring DaaS CORS, and establishing a repeatable workflow for shipping updates.

By the end you’ll have:

Your app live on AWS Amplify with automatic deploys on every merge to main
DaaS CORS configured for the production URL
A repeatable workflow for continuous deployment
An optional custom domain

Prerequisites

A working Buildpad app (either tutorial series completed)
Node.js v24 and pnpm v10+ installed locally

How the Pipeline Works

Buildpad pre-configures the full deployment pipeline when your project is created. By the time you downloaded the starter zip, the following were already in place:

What	Detail
Git repository	Created and managed by Buildpad. Remote `origin` is pre-configured in the starter’s `.git/` directory.
Initial branch	`temporary-local` — your starting point for all development.
AWS Amplify app	Already connected to your git repo, watching `main`. No console setup needed.
Amplify build spec	`amplify.yml` in the project root — runs `corepack pnpm install` then `pnpm build`.
All credentials	Already in `.env.local` — Supabase URL, anon key, service role key, DaaS URL.
Amplify URL	Already in `.env.local` as `NEXT_PUBLIC_MICROSERVICE_URL_MAIN`.

The only deployment trigger you need: merge to main → Amplify builds and deploys automatically.

You don’t need an AWS account, GitHub account, or access to any console. The platform manages the git repository, Amplify app, Supabase instance, and all production secrets.

Understand What Goes Where

There are two categories of configuration. Getting this split right prevents the most common deployment failures:

Secrets (.env.local)

Credentials live in .env.local locally. They are already set in Amplify’s build environment by the platform — you don’t need to add them in the Amplify Console. Never commit .env.local to git.


# .env.local — pre-populated by Buildpad, never committed to git
NEXT_PUBLIC_SUPABASE_URL=https://...db.buildpad.ai
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...
SUPABASE_SERVICE_ROLE_KEY=eyJ...
NEXT_PUBLIC_BUILDPAD_DAAS_URL=https://...daas.buildpad.ai
NEXT_PUBLIC_MICROSERVICE_URL_MAIN=https://main.d1234abcde.amplifyapp.com

Your Amplify URL is the NEXT_PUBLIC_MICROSERVICE_URL_MAIN value.

Update config/app-urls.ts

Read your Amplify URL from .env.local:


grep NEXT_PUBLIC_MICROSERVICE_URL_MAIN .env.local

Update config/app-urls.ts with the value:


// config/app-urls.ts
export const MAIN_APP_URL =
  process.env.NEXT_PUBLIC_HOST_ORIGIN ||
  "https://main.d1234abcde.amplifyapp.com"; // ← paste your actual URL

Commit this file — it’s safe and necessary:


git add config/app-urls.ts
git commit -m "chore: set production Amplify URL"

Configure DaaS CORS

Your DaaS backend rejects requests from unknown origins. Add your Amplify URL using the mcp_daas_cors-settings MCP tool:


{
  "action": "update",
  "cors_origins": [
    "http://localhost:3000",
    "http://localhost:3001",
    "https://main.d1234abcde.amplifyapp.com"
  ],
  "cors_allow_credentials": true,
  "cors_max_age": 0
}

cors_allow_credentials: true is required. Every DaaS call uses credentials: 'include'. If this is false, browsers block all responses — lists show empty, forms silently fail to save.

cors_max_age: 0 forces browsers to recheck the preflight immediately after this change instead of serving a cached (stale) result.

Never use cors_origins: ["*"] when credentials: 'include' is in use. Browsers block wildcard CORS responses for credentialed requests — every single DaaS call will fail.

Develop in a Feature Branch

Start from temporary-local. Never commit directly to main:


# Verify your starting point
git branch
git remote -v
 
# Create a feature branch
git checkout -b feature/initial-deployment
 
# Develop and validate locally
pnpm dev
pnpm install && pnpm build && pnpm test

Always run pnpm build locally before merging to main. A broken build pushed to main triggers a failed Amplify deployment and takes down your production app.

Merge to Main and Watch the Deploy

Push your feature branch and merge to main:


git add .
git commit -m "feat: initial app deployment"
git push origin feature/initial-deployment

Merge to main:


git checkout main
git merge feature/initial-deployment
git push origin main

The moment main is updated, Amplify starts building. Monitor progress via the Buildpad project dashboard. The first build takes 2–3 minutes.

Verify End-to-End

Open your Amplify URL and test the full app flow:

App loads at the Amplify URL
Sign-in succeeds
Protected pages redirect unauthenticated users correctly
Data loads from DaaS (collection lists show real records)
Create, edit, delete operations work
Sign out redirects correctly

Debugging:

Symptom	Likely cause	Fix
Lists empty, forms silent	DaaS CORS misconfigured	Step 3 — check `cors_allow_credentials: true`
Build failed in Amplify	Broken build	Run `pnpm build` locally first, fix errors
`config/app-urls.ts` has localhost	URL config not updated	Step 2 — update and push

Set Up a Custom Domain (Optional)

Contact Buildpad support or your platform admin to connect a custom domain to your Amplify app. Once active, add the custom domain everywhere you used the .amplifyapp.com URL:

DaaS CORS origins (Step 3 — re-run with both URLs)
config/app-urls.ts hardcoded default (commit and push)

Deployment Checklist

Before sharing your production URL:

config/app-urls.ts has the real Amplify URL (not localhost)
DaaS CORS includes the Amplify URL with cors_allow_credentials: true
Full flow verified end-to-end on the production URL
No secrets in git: git log --all -- .env* | head returns nothing

Continuous Deployment Workflow

After initial setup, every update follows the same pattern:


# 1. Create a feature branch
git checkout -b feature/my-change
 
# 2. Develop and validate locally
pnpm dev
pnpm install && pnpm build && pnpm test
 
# 3. Commit and push
git add .
git commit -m "feat: describe your change"
git push origin feature/my-change
 
# 4. Merge to main → Amplify deploys automatically (~2 min)
git checkout main
git merge feature/my-change
git push origin main

Always develop in feature branches — never commit directly to main. This gives you a safe review point and a clean deployment history.

What’s Next

Monitoring — Amplify build logs are visible in the Buildpad project dashboard
Workflow automation — Tutorial 5: Workflow Automation covers validation and notifications useful in production
Custom domain — contact your platform admin to add a domain to your Amplify app