--- title: Sites and deploys description: Understand site identity, deploy history, runtime access, templates, quotas, and usage. audience: everyone status: current last_updated: 2026-10-10 order: 10 related: - /v/docs/getting-started/quickstart.md - /v/docs/ui/building-an-image.md - /v/docs/concepts/tcp-edge.md --- 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: ```text ..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..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..port` | The runtime listener port, independent of the external protocol port. | | `services..public` | Selects the public HTTP service. A non-public service needs separate TCP access authorization to become externally reachable. | | `services..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: ```text /var/run/olibato/tls//tls.crt /var/run/olibato/tls//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](/v/docs/concepts/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.