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