Skip to main content

Web deploys (AWS Amplify)

The web surfaces are hosted on AWS Amplify in us-east-1, one app per product surface. This is a different pipeline from the mobile app (EAS), the Mongo backend (Render), and the Postgres API (ECS). Verified app IDs, platforms, and DNS are on Infrastructure and the AWS system map — this page is the deploy mechanics.

GitHub drape-ai-llc

Amplify auto-build

Amplify auto-build

Amplify auto-build

Amplify git-connected

drape-marketing

drape-brand

drape-admin-v1

drape-docs

drape.to + www

brand + wildcard

admin.drape.to

docs.drape.to

Two Amplify platforms, one org​

  • The three Next.js apps are git-connected Amplify apps on WEB_COMPUTE (Amplify's Next.js server runtime — not a static bucket, despite the repos' output: "export" config). Amplify auto-builds on push. Live Git URLs are https://github.com/drape-ai-llc/drape-* — org, not KCB1099/*.
  • This docs site (Drape-Docs) is platform WEB (static Docusaurus), git-connected to drape-ai-llc/drape-docs, custom domain docs.drape.to (LIVE). It is not amplifyapp-only.
Superseded — do not revive

Amplify is not connected only to KCB1099/*. DNS is not “external / no Route 53.” api.drape.to does not point at Render. This docs site is not manual-deploy / amplifyapp-only in production.

Branch → environment​

BranchEnvironment
mainProduction custom domains
developMarketing Amplify branch (no separate custom domain in the 2026-09-17 inventory)

Postgres backend base URL for the Next.js apps is injected as NEXT_PUBLIC_BACKEND_URL:

  • Production: https://api.drape.to
  • Dev: https://dev-api.drape.to (Route 53 + ALB default action)

staging.drape.to is not in the live Route 53 zone map. If a web app still injects that hostname in code, treat the DNS as stale even if the env var name still says “staging.” CORS notes that mention staging.drape.to should be checked against dev-api.drape.to / *.drape.to before treating them as live allowlist entries.

DNS is Route 53​

Hosted zone drape.to / Z00780563EFBECXPWSBK4 is in this AWS account. Amplify custom-domain setup still emits validation CNAMEs; they are created in Route 53, not an external registrar UI.

HostFront door
drape.to, www.drape.toMarketing Amplify → CloudFront hostname
brand.drape.to, *.drape.toBrand Amplify → CloudFront hostname
admin.drape.toAdmin Amplify → CloudFront hostname
docs.drape.toDocs Amplify → CloudFront hostname
api.drape.to / dev-api.drape.toNot Amplify — Route 53 alias to drape-alb

Brand + wildcard Amplify associations report verified=false while DNS CNAMEs match and domainStatus is AVAILABLE. Documented quirk — do not “fix” by rewriting DNS from this page.

{slug}.drape.to wildcard​

The brand portal's proxy.ts / lib/hosts.ts tenant model is wired at DNS: *.drape.to is a CNAME to the brand CloudFront hostname, and the Amplify domain association includes *. Tenant UX still depends on Amplify cert trust (the verified=false metadata). See Web surfaces.

Docs site build​

Production is the git-connected Amplify app driven by committed amplify.yml. Chromium is installed on the Amplify image so Mermaid can render at build time.

A CLI zip-upload remains an emergency fallback (create-deployment / start-deployment on app d2ip1x1ygwzne5, branch main). Do not treat that as the happy path.

Checklist for a new web surface​

  • Amplify app created (git-connected for CI/CD).
  • main → production (and develop only if a branch is actually attached).
  • NEXT_PUBLIC_BACKEND_URL set per environment (api.drape.to / dev-api.drape.to).
  • Custom domain association created; validation records in Route 53 zone Z00780563EFBECXPWSBK4.
  • Backend CORS updated to allow the new origin (and *.drape.to if it is a tenant host).