Use celld to run Artifacts on infrastructure you manage. For a single-machine local installation, start with the host guide or Docker guide. This page covers operating a deployment backed by object storage, including multiple nodes, TLS, persistence, and upgrades.
Connect your existing sign-in service, such as Google, Okta, or a self-hosted Keycloak server. Artifacts includes Better Auth, the authentication library that connects to these and other OAuth/OIDC providers. If you place the deployment behind Cloudflare Access, that can handle sign-in instead.
The bundled runtime is pinned to celld 0.6.1. This guidance follows the upstream deployment documentation and security model.
For provider setup, MCP sign-in, database requirements, and library permissions, start with authentication and access.
artifacts host (also available as artifacts server) runs the packaged app
through celld dev --no-watch, on loopback with local state. It supports macOS
arm64 and glibc Linux arm64/x64. Background management uses launchd or systemd
user services. No network provider is required. See host commands.
This mode keeps state on one machine. Keep its project path and .celld/dev
data stable across upgrades. Local persistence does not provide
a replicated fleet or protect against losing the machine. A consistent offline
copy requires stopping the service; copying live SQLite files is not a backup
procedure. Preserve the runtime configuration alongside state; configuration
can contain credentials.
For production or multiple machines, use celld's bucket-backed node mode:
- Choose a supported object store with conditional writes and consistent reads. Upstream qualifies Amazon S3, Cloudflare R2, Google Cloud Storage, Tigris, and Azure Blob Storage. Not every S3-compatible provider meets the requirements; consult the storage guarantees.
- Prepare the Artifacts Worker with
bun run build:package, configure application authentication and runtime variables, and deploy the prepared Wrangler project throughcelld deploy. Preserve JavaScript and WASM modules together. Do not carry the local template'sENVIRONMENT=localauthentication bypass into a publicly accessible deployment. - Run a normal celld node against that bucket under systemd, a container orchestrator, or another supervisor. The core host command currently manages the local mode; it does not provision a bucket or launch a production fleet.
- Terminate TLS and authenticate users in the application or a chosen reverse proxy. Keep the operator/peer listener on a trusted private network, with an encrypted overlay when that network does not provide confidentiality.
- Set
CELLD_LTX_RETENTION_SECS(for example,3600) on every node once all nodes run 0.6.1. Without it, celld never deletes superseded snapshot epochs, so bucket usage grows with each activation, including every wake after idle eviction. Epoch deletion requires list-after-write consistency; see the storage guarantees before enabling it on a multi-region bucket. Nodes usingbucketdurability delete nothing. Unset it on every node before rolling back to celld 0.6.0. - Use
/.well-known/celld/healthfor node readiness./healthis an application route and does not establish node readiness. Allow graceful SIGTERM shutdown: the supervisor's stop grace must exceed celld's configured shutdown bound (40 seconds by default), with enough time for the expected drain and handoff. - Update app code through
celld deploy. Running nodes adopt deployments in place; a failed build leaves the previous deployment serving. For runtime upgrades, follow the release-specific shutdown requirements. The 0.6.0 release requires stopping the whole fleet when upgrading from 0.5.1 with fleet durability; bucket durability supports a rolling update. The 0.6.1 release supports a rolling update from 0.6.0. For older installations, check intervening releases.
Two or more nodes reduce write latency through peer durability; a single node waits for bucket persistence. Monitor memory headroom, cold activation queues, and disk space. Reserve capacity for startup and deploys. The local dev supervisor has an internal 30-second listener-announcement deadline; increasing an outer service timeout does not change it.
Moving an existing local .celld/dev installation to a bucket-backed fleet is a
separate data migration. Changing startup flags does not migrate its saved state.