Building an image — Olibato documentation

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:

.olibato/deploy.yaml
.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.

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.<name>.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/<service>/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 for commands and readiness; the grant URI is mysql://<routing_username>@<host>: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.