| Thing | Value |
|---|---|
| Manifest version | 1 |
| Service name regex | ^[a-z][a-z0-9-]{0,30}$ |
| Public-port prefix regex | ^[a-z][a-z0-9-]{0,30}$ |
| Secret / variable name regex | ^[A-Z][A-Z0-9_]*$ |
| Public ports per service | 1 |
| Pod replicas per service | 1 |
| Ephemeral deploy TTL — default | 5 minutes |
| Ephemeral TTL clock starts | when status reaches healthy |
| ”Concurrent deployments” unit | active environment instance (base env = 1 regardless of repo count; each preview / dev / manual instance = +1) |
| Manual instance TTL — default | the plan’s deployment TTL, or 24 hours when the plan has none |
| Public host shape | <env-name>-<service>-<id>.<apps-base> (<id> = 8 hex from the env-instance UUID) |
| Host stability | Stable across redeploys; an instance keeps its <id> for its lifetime |
| Invite expiry | 7 days |
| Storage overage hard ceiling | 4× the plan’s included storage (on plans that bill overage) |
| Log retention | 30 days |
| Usage metrics retention | 30 days (sampled every 30s — see Metrics) |
| Deployments list default page size | 15 |
| Repos list default page size | 24 |
| Max page size on any list | 100 |
| Request body cap (app traffic) | 10 MB (413 beyond it) |
Edge rate limits
Plans can carry a per-client-IP request rate (sustained requests/second, with a burst allowance) and a per-client-IP concurrent-request cap, enforced at the platform edge for every public service — platform subdomains and custom domains alike. A client that exceeds them receives 429 Too Many Requests; other clients of the same service are unaffected. These are abuse guards against a single hot client, not a cap on how much total traffic a service may serve. Open Settings → Billing to see your org’s live values; unlimited means no edge throttle is applied. There is no upstream response timeout at the edge — long-lived SSE and WebSocket connections are not cut off.Per-deployment resources
Every deployment runs with CPU, memory, and disk caps that come from your plan. The numbers aren’t fields inslipway.yaml — they apply automatically. See Plans & pricing for the current per-plan caps, or open Settings → Billing to see the live values for your org.
Each container gets a CPU limit (the ceiling) and a CPU request (the guaranteed share) from your plan; when the request is below the limit, the container can burst up to the limit whenever the node has headroom. Memory is always fully guaranteed at the limit — there is no memory burst, because memory can’t be throttled.
If a build asks for more than your plan allows, the deploy fails at the deploy phase and the deployment detail page tells you exactly which cap was exceeded.
Storage overage
Named-volume storage is an org-wide budget (see Plans & pricing). What happens when you exceed your included storage depends on the plan:- Plans with an overage rate (e.g. Team, Business) treat included storage as a soft cap. You may provision past it up to a hard safety ceiling — 4× the included amount — and the GB over the included line are billed as metered overage on your next invoice at the plan’s per-GB-month rate. Provisioning past the safety ceiling is refused.
- Plans without an overage rate (e.g. Starter) treat included storage as a hard cap: provisioning past it is refused until you free space or upgrade.