--- title: Building an image description: Build, validate, review, and deploy a version for a site from authorized source. audience: owner status: current last_updated: 2026-10-13 order: 10 related: - /v/docs/concepts/sites-and-deploys.md - /v/docs/getting-started/quickstart.md - /v/docs/concepts/tcp-edge.md --- An Olibato build turns one authorized source revision into an immutable version for a site. Source can come from a GitHub repository, a committed local Git archive, or a container reference. The deploy records source identity, resolved manifest, agent activity, runtime trial, health result, and security result so the owner can review the evidence before activation. ## Connect the repository Create or open the target site, choose the repository source, and complete the GitHub authorization flow. Olibato should receive only the repository access required for the selected installation. Repository content is untrusted input to the isolated build process. Alternatively, choose **Upload local Git**. Supply a full 40- or 64-character commit SHA and an archive containing that revision. Local source is screened for unsafe archive paths, links, oversized expansion, and common credential markers, then converted to a deterministic archive before it enters the build queue. Olibato deletes the source bytes when the build becomes terminal and retains only source-free provenance. Uploading content represents the account owner's authorization to process it; it is not a license attestation. ## Choose the configuration source Olibato probes manifest paths in this order: 1. `.olibato/deploy.yaml` 2. `.serverl3ss/demo.yaml` for backward compatibility If either known path is configured or the configuration path is empty, the first existing candidate wins. A custom owner-supplied path is resolved exactly and does not trigger the probe. When no manifest exists, the agent may generate `.olibato/deploy.yaml` for review. The manifest schema version remains `version: 1`; changing the preferred path does not change the content schema. ```yaml version: 1 runtime_backend: gvisor build: steps: [] services: web: image: registry.example.com/product:validated port: 3000 protocol: http public: true health_check: kind: kernel timeout_ms: 60000 ``` The example shows the shape of a simple manifest, not a universal configuration. Use the service topology, image provenance, health checks, and initialization requirements verified for the repository you are building. For gVisor services with a declared TCP `port`, `health_check.kind: kernel` gates launch and wake on a process parked on that port's listening socket. It does not execute an application probe or check the response body. An optional `health_check.command` supplies an exec fallback if the installed runsc lacks readiness inspection. Omit `kind` (or set `exec`) to retain the command-based gate. Kernel checks without a gVisor runtime and declared service port are rejected at admission. Existing published version snapshots retain their recorded health checks. ### Agent-generated service fields Generated manifests use the same `version: 1` validator as supplied manifests. Review an explicit `services..protocol` (`http`, `postgres`, `mysql`, `redis`, `amqp`, `tcp`, or `mongodb`) for each service. Service names describe topology; the source edge policy keys on protocol. An omitted protocol is intended to mean internal-only, but current normalization to `tcp` can still admit grants when `tls: {}` is present. Declare protocols explicitly and withhold grants for internal services. The validator retains the legacy omitted-protocol `database`@5432 inference; declare `postgres` explicitly for new database services. The optional `tls: {}` marker requests a platform service certificate. It is valid only for non-public services other than MySQL. Configure the application to read `/var/run/olibato/tls//tls.crt` and `tls.key`, with the CA bundle at `/var/run/olibato/tls/ca.crt`. Managed issuance and delivery are implemented and tested for gVisor mounts, Firecracker disk material, and K3s Secrets; local Redis integration tests use real certificates. Verify the deployed endpoint's TLS readiness separately from schema acceptance. Keep credentials and key bytes out of generated source. `connect.scheme` is an optional display hint, such as `rediss`, alongside the required `connect.message`; it does not enable TLS or expose a service. For Redis/Valkey, review TLS-only startup (`--tls-port 6379 --port 0`), the service certificate paths, and authentication using ACL user `app`. The seeded ACL disables `default` and excludes `@dangerous` commands. For MySQL/MariaDB/WordPress, omit the template username override to obtain `u_{{ site.token }}`, resolved from the persisted site ID. Inspect that concrete username in the resolved manifest; it is the gateway routing identity; WordPress uses it for both database user settings. The build agent must preserve these validated fields in its proposal and report missing runtime/edge support as a readiness blocker. Edge components are implemented and tested; an agent-authored manifest or successful build does not prove the public listener rollout is active. ## Review the proposed build The AI-assisted analysis proposes a reviewable configuration; it does not bypass owner review. Confirm the detected public service, runtime backend, required initialization, resource bounds, and any build adaptation before starting or accepting a build. ## Follow validation evidence A ready image version must complete the relevant build, runtime trial, health check, and security scan. If trusted infrastructure fails, repair or retry that infrastructure failure instead of treating it as proof that the repository cannot run. If the application trial fails, revise the general topology or build configuration using the recorded evidence. ## Review the candidate version Open the validated candidate through the authenticated owner review action. Verify the application content and its important interactions, then return to the site to activate the version or rebuild from corrected configuration. ## Activate the version Activating a ready version updates the existing site; it does not create a new hostname. The site's isolated runtime uses the selected version on its next wake or restart. Writable runtime state remains attached to that site unless an owner explicitly resets it. For a new site, confirm the public service, access setting, and idle policy before activation. A later rebuild creates another immutable version and never silently changes which version is active. ## Connect to the deployed services HTTP uses the site's HTTPS host on 443. Private services need an owner TCP grant, service hostname, application credentials, and verified TLS. On the implemented edge, PostgreSQL uses 5432, MySQL/MariaDB the TLS gateway on 3306 with the site-unique routing username, Redis/Valkey TLS on 443 with ACL user `app`, and AMQPS on 5671. Other protocols require client-first TLS on 443 and an approved binding. Follow [TCP edge](/v/docs/concepts/tcp-edge/) for commands and readiness; the grant URI is `mysql://@:3306` for MySQL and generic `tcp://` for other protocols; neither is proof of external connectivity. Client connections do not survive checkpoint/restore, snapshots, restart, or idle scale-to-zero. Configure reconnect behavior and verify uncertain write outcomes. Durable state persists; keepalives hold the instance awake and that awake time is billable.