A site is the durable product record at the center of Olibato. Deploys may replace its active application version, and its runtime may sleep or move, while the site slug and permanent host remain unchanged.
Site, slug, and namespace#
Each account chooses a personal namespace during signup. Organizations use their organization slug as a namespace. A site has a unique slug within its namespace:
<site>.<namespace>.serverl3ss.com
For example, site web1 in namespace mike is
web1.mike.serverl3ss.com. The namespace and site slug are immutable DNS
identities. A site name is display text and may change. Custom domains are
additional verified hosts for the same site.
Deploys and versions#
A deploy combines a source input with a validated deploy.yaml manifest. Source
may be a container image, connected GitHub repository, committed local archive,
or app template. Build events and evidence belong to that deploy.
A successful deploy produces an immutable version. The site points at one active version, so a later deploy can change application code or topology without creating a new site. The isolated runtime uses that version and retains its own writable state. Suspending, waking, restarting, or moving the runtime does not change the permanent host.
App templates#
App templates are supported recipes for common open-source services. Each template declares its parameters, license, source image, service topology, and default access. Installing one renders a manifest and sends it through the same validation, security, deploy, and version process as other sources. Templates do not bypass runtime isolation or quota checks.
When a template version's inputs match a verified shared build artifact on every active node, selecting it publishes a site-owned version and skips the builder queue. Each site still receives its own rendered manifest, credentials, and writable volumes. While the fast path is enabled, the template picker offers only versions that are warm on every active node; a direct deploy of a version that has not been warmed takes the normal build path instead. Initial application startup and TLS provisioning still take time after the build is skipped.
Every curated template requests at most half of the Free-tier aggregate —
250 millicores, 256 MB memory, 128 processes, and at most 512 MB disk — so
any template activates on the Free tier and leaves the other half of the
site's ceiling for a paired service. MongoDB is the one exception: mongod
refuses to start with a WiredTiger cache below 0.25 GB, so MongoDB keeps the
Free tier's full 512 MB memory ceiling while staying admissible on Free; its
CPU, process, and 250 MB disk requests still sit at half or below. These are
fixed requests, independent of the HTTP application resource presets. The
other databases are tuned for the 256 MB envelope: MySQL and MariaDB run with
a 64 MB InnoDB buffer pool and the performance schema off, and PostgreSQL
runs with 64 MB shared buffers and at most 20 connections. RabbitMQ's
256 MB request is its official minimum, and memory flow control engages
early, around 100 MB of effective use. Redis and Valkey use noeviction:
writes fail when their 200 MB data limit is full rather than silently
evicting existing keys.
MinIO requests 256 MB and uses the digest-pinned public Bitnami Legacy image
for the July 23, 2025 MinIO release. Use path-style S3 bucket addressing over
the site's HTTPS hostname. The template sets MINIO_SERVER_URL to that hostname
so presigned URLs use the public origin; the separate console port is disabled.
Manifest services and protocols#
The additive service fields keep version: 1. A manifest defines build and
exactly one of run or services. Service names are free-form identifiers for
dependencies and runtime topology; firecracker-kube requires lowercase DNS
labels. The edge policy source selects a protocol, never a special service name;
TCP provisioning additionally requires a safe endpoint identifier.
| Field | Meaning |
|---|---|
services.<name>.protocol |
Optional enum: http, postgres, mysql, redis, amqp, tcp, mongodb. Selects the intended external reachability policy; it does not create a route or grant. |
services.<name>.port |
The runtime listener port, independent of the external protocol port. |
services.<name>.public |
Selects the public HTTP service. A non-public service needs separate TCP access authorization to become externally reachable. |
services.<name>.tls: {} |
Requests platform-managed certificate delivery for the service hostname. The application must listen with TLS; this marker does not configure the server. |
connect.scheme |
Optional connection display hint, such as rediss. It does not select a listener, change routing, or enable TLS. connect.message remains required when connect is supplied. |
Omitting protocol is intended to make a new private service internal-only.
The validator currently normalizes it to tcp, and the edge policy can admit
that normalized service when tls: {} is present. Strict omitted-protocol
isolation is not enforced yet: declare protocols explicitly and withhold grants
for internal services. Generic TCP externally requires client-first TLS.
Compatibility exception: an existing
non-public database service on runtime port 5432 with an omitted protocol is
normalized to postgres. Explicit protocol: tcp overrides that inference.
Declare the protocol explicitly in new manifests.
tls accepts only an empty map. It is invalid on a public HTTP service and on
protocol: mysql: the MySQL gateway terminates external TLS and connects
to the private database backend. The per-service delivery convention is:
/var/run/olibato/tls/<service>/tls.crt
/var/run/olibato/tls/<service>/tls.key
/var/run/olibato/tls/ca.crt
Use the assigned service hostname for SNI and certificate verification. Service certificates and keys are independent of the web namespace wildcard certificate; never embed private keys in manifests or images.
The validator and template renderer accept these fields. Managed certificate issuance and delivery are implemented and tested for gVisor mounts, Firecracker disk material, and K3s Secrets, including local real-certificate Redis tests. Verify public deployment and each application's TLS startup independently. See TCP edge for the port map, implementation status, and connection requirements.
MySQL, MariaDB, and WordPress template username defaults are u_{{ site.token }}. Rendering
substitutes the persisted site's ID, producing a stable, site-unique username.
Omit params.username to use this default and inspect the resolved deploy
manifest for its concrete value. Redis and Valkey templates use TLS-only
listeners with the ACL user app, disable the default user, and exclude
@dangerous commands from the app user's permissions.
Access control#
HTTP sites are either public or authenticated. Authenticated access is enforced before a sleeping workload wakes. Private TCP services use temporary, source-IP grants with explicit expiry; application-level database credentials still apply.
Client connections do not survive instance recycle: checkpoint/restore, snapshots, restart, or idle scale-to-zero requires clients to reconnect. Configured durable state persists; an open connection or in-flight transaction is not durable state. Use reconnecting clients and resolve uncertain transaction outcomes before retrying writes. Client keepalives hold the instance awake and that awake time is billable.
Custom domains inherit the site's access setting. Olibato verifies ownership and traffic DNS before routing a custom hostname and periodically checks ownership while it remains active.
Quotas and usage#
Quotas bound sites, custom domains, services, compute, memory, retained storage, and monthly wake time for a namespace. Creating a site or starting a deploy may be rejected before work begins when a hard limit is reached.
Usage is measured per site and rolled up to the namespace. The dashboard and API report request count, wake minutes, and retained storage for the current period. Usage records are append-only, so deleting a site does not erase its audit trail.