Beta limits and retention

Stead is a bounded hosted beta. Use Diagnostics or getstead doctor for your project’s current state and actionable limits. Configuration limits below describe the current hosted implementation; they are not a promise of unlimited capacity or availability.

Resource	Allowance or behavior
Projects	10 per personal organization.
Active project credentials	20 per project.
Private project database	512 MiB memory and a 1 GB volume, including PostgreSQL overhead.
Database allocations	25 across the beta installation; new provisioning waits/refuses when full.
SQL scratch files	64 MiB per database backend. Temporary tables are unavailable.
Handler bundle	512 KiB before base64 encoding.
Deployment retention	At most 32 stored versions and 256 MiB of bundle storage per project.
Run history	At most 1000 stored runs per project.
Run event storage	256 MiB per project, including reservations for unfinished runs.
Events within a run	8 MiB and 1024 events, plus reserved space for a final record.
Customer data reads	Default 100 rows, maximum 1000; exposed columns and equality filters only.
Conversation history page	Default 100 messages, maximum 1000, also bounded by response size.
Program steps	1–100 per run.
Customer input	Up to 100000 characters; no control characters except tabs/newlines.

Run execution, uploads, data reads, auth requests, streams, and handler runtimes have additional concurrency and time limits. Capacity refusals should be retried with backoff, respecting Retry-After when present. Do not launch an unbounded retry loop or keep creating replacement projects.

History is not an archive

When run-count or event-storage admission reaches its limit, new starts can reclaim terminal runs last updated more than 24 hours ago. Reclamation includes those runs’ traces, charges, approvals, and conversation messages. Recent and unfinished runs remain available; existing work can still finish or cancel.

Older deployment versions are cleaned during deployment. Versions needed by unfinished runs remain available. Finish or cancel those runs if required versions fill the allowance, then retry the deployment.

Export any records your application must retain long term. Saved conversations survive ordinary reloads and sign-outs, but they are subject to history retention.

Database storage

Diagnostics distinguishes an unprovisioned, provisioning, recovering, capacity-limited, ready, or storage-limited database. Provisioning and recovery retry automatically. A full allocation pool prevents new databases, rather than silently sharing another project’s database.

When storage is nearly full, customer reads remain available and customer writes pause. Deploy a reviewed migration that drops or truncates unused data or indexes to return disk space. Deleting rows alone may not shrink the files. Writes resume after space is restored; the service keeps a separate recovery reserve, shown in Diagnostics when telemetry is available.

Supported scope

The beta provides email/password customer authentication, trusted-backend identity exchange, deployed tool/model programs, curated provider models, customer-scoped SQL data access, owner approvals, streamed runs, and bounded saved conversations.

It does not expose a public raw-SQL query endpoint, a database connection string, customer self-approval, arbitrary browser-supplied programs, a permanent transcript archive, or a public custom-model registration workflow. A private project database does not make an incorrectly written RLS policy safe. Approval and recovery do not undo external effects.

The starter’s sample refund is a database demonstration, not a payment integration. Provider usage is billed by your provider; per-run budgets are execution controls, not a guarantee of the final external invoice.