# Deployment Guide

> How a project gets onto **rethink-net** — our Ubuntu 26.x servers. Get your
> container to follow a few consistent rules and deploying is mostly handing us a
> `compose.yaml`.

!!! tip "What can run here"
    APIs, websites, applets, bots, monitors.

!!! danger "Your compose names nothing repo-specific"
    **No `container_name`. No hardcoded names, workspace, or `/srv` paths.** The
    deploy layer injects identity and host paths at deploy time — your compose stays
    generic so it can't collide with any other service on the fleet.

    - service key is always **`svc`**
    - named volumes use **bare names** (`cache`, not `myapp_cache`)
    - host paths come from **`${LOGS_DIR}` / `${CONFIG_DIR}`**

    Naming things after your repo used to cause **container-name collisions** at
    fleet scale — two repos shipping the same name clashed. The generic compose
    convention fixes that.

!!! note "You don't run any deploy commands"
    All services are deployed centrally by the ops tooling. You don't pick a host,
    manage keys, or run anything — just make your repo follow the compose convention
    and it's deployable. At deploy time the tooling **generates** the environment your
    compose reads (`${LOGS_DIR}`, `${CONFIG_DIR}`, optional `${MOUNTS_DIR}`), so the
    same file works locally and on the fleet.

## The three things your repo needs

<div class="grid cards" markdown>

-   :material-file-cog: __[Compose convention](compose.md)__

    ---

    The `compose.yaml` your repo ships — generic `svc` service, the `${...}` host
    mounts, storage tiers, and how deploy fills it in.

-   :material-docker: __[Dockerfile & build](dockerfile.md)__

    ---

    The uid-agnostic image (services account 1337), getting files in with `COPY`,
    layer caching, uv, and subprocess/browser workloads.

-   :material-key: __[Secrets](secrets.md)__

    ---

    How secrets stay out of the image and reach the container read-only at runtime.

</div>