Application build contract

Backify builds one immutable container image. The same digest runs as web, worker and migrate roles and is promoted unchanged. Read application support before adapting a framework.

Inputs and checks

• backify.config.ts: typed app intent, frontend output, auth, buckets, secret names and allowed HTTP hosts.
• Module-top-level declarations in @backifydev/sdk/app: routes, jobs, schedules and event subscriptions.
• backify.lock.json: generated by backify lock, committed, with OpenAPI and migration hashes.
• New SQL files in db/migrations; never edit applied files.
• A repository-root Dockerfile whose entrypoint runs the SDK's backify-run role.

Describe mode loads declarations without database credentials, secrets or workload tokens. Import-time network/database connections fail. This is a reproducibility check, not an OS sandbox; do not execute untrusted application source.

CI and intake

CI runs backify check, builds and verifies the image, pushes it, then sends multipart POST /api/apps/{appId}/releases with image (registry/repository@sha256:digest), commit (full SHA), lockfile, optional migrations (migrations.tar), and frontend (frontend.tar.gz for web apps).

The server validates the lockfile and policies, verifies migration hashes, stores assets and queues preview deployment. The worker no longer clones source or installs dependencies. Image tags are insufficient.

The pipeline validates, plans, provisions, runs migrations, stages process roles and checks health before activation. Migrations use an isolated credential; ordinary processes use the limited runtime role. Removing stateful resources requires explicit confirmation.

An image check does not verify browser interactions, real sign-in, external integrations or provider consent. Verify those in preview and report actual results. See preview releases and the runtime contract.