Skip to content

Vercel, Render, and Supabase

The hosting and data stack for ventures. Read this before you create any project.

Each venture starts from its GitHub repo in the scailetech org — that repo is the source of truth, and Vercel and Supabase are provisioned from it. Find any venture's repo in the GitHub map.

The scailetech rule — hard, zero exceptions

Every venture's infrastructure lives under the scailetech organization — on GitHub, Vercel, and Supabase. Never a personal account, never "I'll move it later."

A project created under a personal scope is misaligned infrastructure: it isn't visible to the team, it isn't covered by the company plan, and someone has to migrate it. This caused real problems on the first venture build. If you do not yet have scailetech access on GitHub, Vercel, or Supabase, request it on day 1, before writing any code — see who-grants-what.md.

A reliable habit: the first thing you do in any dashboard is check the org/team switcher (top-left) reads scailetech, not your name.

Vercel — front-end

Front-end deploys for ventures and client sites. You deploy on assigned ventures; never push to production without sign-off (preview deploys are yours).

Create a Vercel project under scailetech

  1. Sign in at vercel.com with your @scaile Google Workspace account.
  2. Open the team switcher (top-left) and select scailetech. If you don't see it, you lack access — request it and stop here; do not continue under your personal account.
  3. Add New → Project → import the venture's GitHub repo (which must already live in the scailetech GitHub org — see the GitHub map).
  4. Before deploying, confirm the Team shown on the configure screen is scailetech. Set the project name to the venture slug (see naming conventions).
  5. Add environment variables (see secrets below), then deploy. The first deploy is a preview.

Render — back-end

Back-end and API hosting. You do not touch Render by default — it is engineering's surface. Read it for context; don't deploy to it.

Supabase — database / auth / storage

Postgres database, auth, and storage for ventures. Same hard rule: it lives under the scailetech org.

Create a Supabase project under scailetech

  1. Sign in at supabase.com with your @scaile Google Workspace account.
  2. Open the organization switcher (top-left) and select scailetech. If it's not there, request access and stop — never create the project under a personal org.
  3. New project → confirm the org is scailetech → name it the venture slug (<slug>, or <slug>-dev / <slug>-prod if you split environments).
  4. Region: for DACH / German ventures choose an EU region (Frankfurt) — data residency and GDPR. Match the region to the target market.
  5. Set a strong database password and save it to Bitwarden immediately.
  6. From Project Settings → API, copy the project URL and keys. Store secrets as below.

Secrets

Supabase keys and DB password, API keys, tokens — all of it:

  • Bitwarden is the system of record for credentials.
  • Put runtime values in the project's environment variables (Vercel project settings, and your local .env which is git-ignored).
  • The anon key is client-safe; the service-role key is a server-only secret — never ship it to the browser.
  • Never commit secrets to git or paste them in Slack.

The handoff line

The precise line where FA deploys end and engineering takes over is still to be confirmed with August (see the open question below). Until then the default holds: preview deploys are yours; never production without sign-off.

Open questions

Question Owner Urgency
Vercel handoff line — when does FA deploy vs hand to engineering? August Low

Owner: Current FA Last reviewed: 2026-07-03