# TAPM Deployment Access

TAPM Deployment Access is a short-lived authorization broker for protected
deployment packages and installer actions. Technicians authenticate through
the bundled Git service, create deployment codes, and authorize a limited
number of hosts for selected capabilities.

The production layout is a self-contained, single-VM Docker deployment:

- Go broker with a persistent embedded SQLite database
- rootless Git service with SQLite, repositories, and package registry
- Nginx reverse proxy for both public domains
- Certbot and Let's Encrypt HTTP-01 certificate management
- explicit runtime storage under `config/` beside the Compose files
- privacy-minimized ProxMenu installation and run-status registry

No external database or load balancer is required. The datacenter edge only
needs to forward public TCP 80 and 443 to the configured Docker VM ports.
All services are managed by one Compose project while remaining separate
containers for independent health checks and upgrades.

See [docs/deployment.md](docs/deployment.md) for the installation, Git setup,
TLS bootstrap, repository move, renewal, backup, and update procedures. The
ProxMenu integration contract is in [docs/client-api.md](docs/client-api.md).

## Guided installation

After cloning the repository, run:

```sh
./install.sh
```

The installer defaults to `SSL_MODE=none`, writes a mode-`0600` `.env`, creates
the runtime directories and Docker network, and starts Git behind the
HTTP-only Nginx test configuration. It does not invent Git OAuth or package
credentials. After creating those resources in Git, run
`./manage.sh configure-broker` and `./manage.sh start`.

New deployment codes default to seven days. While a code is active, the Codes
page can raise or lower its host limit, add or remove packages and installer
actions, and extend its expiration in whole days. The host limit cannot be
reduced below the number of hosts already enrolled, and every change is
recorded in the audit trail.

Once public DNS and TCP 80/443 forwarding are ready, switch the same persistent
deployment to Let's Encrypt:

```sh
./manage.sh set-ssl letsencrypt
./manage.sh bootstrap
./manage.sh start
```

## Nginx configuration

At first `install.sh` or `manage.sh` run, the deployment copies its editable
Nginx templates to `config/nginx/`. Those local files are never overwritten by
an update:

- `bootstrap.conf.template` serves the Let's Encrypt HTTP-01 challenge.
- `http.conf.template` is used only in `SSL_MODE=none` test mode.
- `tls.conf.template` is the active production HTTPS reverse-proxy template.
- `sites/*.conf` is included by the HTTP and TLS templates for additional
  virtual hosts.

After editing a template or site snippet, recreate Nginx to render templates
and apply the configuration:

```sh
./manage.sh reload-nginx
```

The command selects the active HTTP or TLS configuration and validates Nginx
after recreating it. Keep certificates in `config/ssl` or `config/letsencrypt`;
they remain read-only mounts separate from the editable Nginx configuration.

## Local checks

```sh
GOCACHE=/tmp/tapm-go-cache go test ./...
docker compose --env-file .env.example config
docker compose --env-file .env.example \
  -f compose.yaml -f compose.http.yaml config
docker compose --env-file .env.example \
  -f compose.yaml -f compose.tls.yaml -f compose.direct.yaml config
docker build -t tai/tapm-deployment-broker:local .
```