[7ttp]

TL;DR

stack start now supports [api.tls]the api serves https on its usual port with legacy's cert, and containers keep talking plain http like before..

whats introduced?

• one port, both protocols. the api port reads the first byte of each connection: a tls hello gets https, anything else gets plain http, but only from its machine and its containers
• urls move to https (API_URL, auth links, studio's public url, the functions banner), while containers and pg_net keep their plain runtime urls
• legacy's embedded cert by default, or your own cert_path and key_path.
  it's checked before anything starts and saved with the stack, so storage commands keep trusting it
• on docker and podman, start makes sure containers can still reach the api, and stops the stack if they can't
• turning tls on or off applies on the next stack start. without it, nothing changes

visual rep:

flowchart LR
  host["cli, sdk, browser<br/>on this machine"] --> port{{"api port<br/>reads the first byte"}}
  ctr["auth, studio,<br/>functions, db"] --> port
  lan["lan peer"] --> port
  port -- "tls hello" --> https["https<br/>the api, for anyone"]
  port -- "anything else" --> who{"this machine or<br/>its containers?"}
  who -- "no" --> closed["closed<br/>nothing sent back"]
  who -- "yes" --> named{"stack Host?"}
  named -- "no" --> misdirected["421"]
  named -- "yes" --> plain["plain http<br/>the api and /email templates"]
  https -. "/email" .-> hidden["404"]
  classDef t fill:transparent
  class host,ctr,lan,port,https,who,closed,named,misdirected,plain,hidden t

Loading

ref

• closes: CLI-2584
• supersedes: chore(stack): support gateway routes TLS and Auth templates #6803

[github-actions]

CLI benchmark (Lightweight Commands): no changes found

Commit 66b8b99 against develop at d4fc0e5 · 10 runs each · report only, never blocks merging

Command	Workload	Before	After	Change
supabase --version	version	330 ms	284 ms	no real change (-14%, within normal variation)
supabase --help	help	414 ms	384 ms	no real change (-7%, within normal variation)
supabase init	init	391 ms	378 ms	no real change
supabase migration new bench	migration-new	621 ms	642 ms	no real change
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	314 ms	385 ms	no real change (+22%, within normal variation)
supabase projects list	projects-list	256 ms	255 ms	no real change
supabase functions list --project-ref replayfixtureprojref	functions-list	268 ms	272 ms	no real change

API calls: unchanged for all 7 commands.

Binary size: 134.9 MB, up 28.0 KB from 134.9 MB.

Details: timing ranges, API calls per command, slowest phases

Timing ranges

Command	Workload	Before range	After range	Change	Verdict
supabase --version	version	228-399 ms	248-457 ms	-46 ms (-14%)	within noise
supabase --help	help	289-659 ms	336-568 ms	-31 ms (-7%)	within noise
supabase init	init	322-497 ms	332-479 ms	-13 ms (-3%)	within noise
supabase migration new bench	migration-new	502-909 ms	559-930 ms	+21 ms (+3%)	within noise
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	282-501 ms	303-607 ms	+71 ms (+22%)	within noise
supabase projects list	projects-list	227-273 ms	235-304 ms	-2 ms (-1%)	within noise
supabase functions list --project-ref replayfixtureprojref	functions-list	237-328 ms	242-287 ms	+4 ms (+2%)	within noise

API calls per command

Command	Workload	Before	After	Endpoint changes
supabase --version	version	0	0
supabase --help	help	0	0
supabase init	init	0	0
supabase migration new bench	migration-new	0	0
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	2	2
supabase projects list	projects-list	1	1
supabase functions list --project-ref replayfixtureprojref	functions-list	2	2

Slowest phases

No command moved beyond noise, so there are no phase deltas.

Workflow run

Comment /bench to run the lightweight benchmark (this comment) again on the latest commit, or /bench full to also run the integration-heavy benchmark, which posts in its own comment.