---
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-09-02
order: 10
related:
  - /v/docs/concepts/sites-and-deploys.md
  - /v/docs/getting-started/quickstart.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
services:
  web:
    image: registry.example.com/product:validated
    port: 3000
    public: true
```

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.

## 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.