You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: Beyond the published container image name (#4770) and the config filename (#4773), the self-host deployment surface still threads the old brand name through the actual deployment plumbing: the docker-compose service key, its volumes and secrets, a Tailscale hostname, the compose project name, the Caddy reverse-proxy target, the systemd unit files operators install verbatim, and several helper scripts. docker-compose.yml names the compose service gittensory (~line 75), defines a volumes block with gittensory-data/gittensory-pg/gittensory-backups (~lines 1024-1040), Docker secrets gittensory_api_token/gittensory_mcp_token backed by ./secrets/gittensory_*.txt, a Tailscale hostname gittensory (~line 845), and COMPOSE_PROJECT_NAME: ${COMPOSE_PROJECT_NAME:-gittensory} (~line 783) — the latter is the effective container-name prefix self-hosters see in docker compose ps since there's no explicit container_name override. docker-compose.override.yml.example repeats the same service key (lines 1, 7, 24, 30, 33, 50), including an override stanza gittensory: at line 50, and references systemd/gittensory-docker-prune.*.example. caddy/Caddyfile (lines 1, 8, 12) reverse-proxies to gittensory:8787 by compose service name — if the service key renames without this file changing in the same commit, the proxy silently 502s against the wrong upstream host. systemd/gittensory-docker-prune.service.example and .timer.example carry the brand in their filenames, in Description=Gittensory self-host Docker resource hygiene..., in WorkingDirectory=/opt/gittensory, in ExecStart=/bin/sh /opt/gittensory/scripts/..., and in the systemctl enable --now gittensory-docker-prune.timer command operators copy straight out of the comments. Several shell scripts carry the same identifiers: scripts/deploy-selfhost-image.sh (SERVICE default), scripts/selfhost-init-secrets.sh (SECRET_FILES array: gittensory_api_token.txt, gittensory_mcp_token.txt), scripts/selfhost-update.sh (error message referencing "the gittensory git checkout"), and scripts/backup.sh (DB default /data/gittensory.sqlite, output filenames gittensory-<ts>.dump/.sqlite). Adjacent to this, k8s/miner-deployment.yaml — a separate deployment artifact for gittensory-miner fleet mode — has the same pattern in its own scope: StatefulSet name gittensory-miner, label app.kubernetes.io/name: gittensory-miner, serviceName: gittensory-miner, image gittensory-miner:latest, env var GITTENSORY_MINER_CONFIG_DIR, and secret name gittensory-miner-secrets.
Area: Infra / Self-host
Proposal:
Open question (needs a maintainer decision before starting): Does the docker-compose service key itself (gittensory: in docker-compose.yml and docker-compose.override.yml.example) get renamed, or does it stay as-is? Unlike the published image name in #4770, which is customer-facing, the compose service key is arguably an internal implementation detail — but renaming it is a breaking change for every self-hoster's own docker compose exec gittensory ... muscle memory and for any docker-compose.override.yml customization they've already layered on top. Need a decision on which way this goes before touching the file.
Once that's settled: rename the volumes, Docker secrets and their backing file paths, the Tailscale hostname, and the COMPOSE_PROJECT_NAME default in docker-compose.yml, carrying the same choice through to docker-compose.override.yml.example. If the compose service key does change, update caddy/Caddyfile's reverse_proxy target in the same commit so the proxy doesn't silently start 502ing against a stale upstream host. Rename the systemd/gittensory-docker-prune.*.example unit files (and their Description=, WorkingDirectory=, ExecStart=, and systemctl enable --now ... install commands), and update the identifiers threaded through scripts/deploy-selfhost-image.sh, scripts/selfhost-init-secrets.sh, scripts/selfhost-update.sh, and scripts/backup.sh. Handle k8s/miner-deployment.yaml as its own pass since it's an adjacent, separate artifact (gittensory-miner fleet mode) rather than part of the core self-host compose stack.
Deliverables:
Updated docker-compose.yml and docker-compose.override.yml.example reflecting whatever the compose-service-key decision lands on.
Updated caddy/Caddyfile reverse-proxy target, kept in lockstep with the compose service key.
Renamed systemd/gittensory-docker-prune.service.example / .timer.example files with updated internal contents and install-command comments.
Updated identifiers in scripts/deploy-selfhost-image.sh, scripts/selfhost-init-secrets.sh, scripts/selfhost-update.sh, and scripts/backup.sh.
Maintainer decision on the compose service key is recorded and implemented consistently across docker-compose.yml and docker-compose.override.yml.example.
caddy/Caddyfile's reverse-proxy target matches the compose service name exactly — no 502s from a stale upstream host.
Renamed systemd unit files install and run cleanly via the updated systemctl enable --now ... commands.
k8s/miner-deployment.yaml is internally consistent (name, labels, serviceName, image, env var, secret name all agree).
Test scenarios:
Bring the stack up with docker compose up against the updated files and confirm the Caddy reverse proxy resolves to the running service without a 502.
Install and start the renamed systemd unit/timer pair on a test host and confirm they run without a path or naming mismatch.
Run scripts/selfhost-init-secrets.sh and scripts/backup.sh end-to-end and confirm the secret files and backup output filenames use the new identifiers consistently.
Deploy k8s/miner-deployment.yaml to a test cluster and confirm the StatefulSet, service, and secret all bind correctly under the renamed identifiers.
Leave every reference to the separate gittensor network's own domain/name untouched.
Don't rename the compose service key until the open question above is decided — a rename without deciding that first will leave the Caddyfile and every self-hoster's existing override file out of sync.
Problem: Beyond the published container image name (#4770) and the config filename (#4773), the self-host deployment surface still threads the old brand name through the actual deployment plumbing: the docker-compose service key, its volumes and secrets, a Tailscale hostname, the compose project name, the Caddy reverse-proxy target, the systemd unit files operators install verbatim, and several helper scripts.
docker-compose.ymlnames the compose servicegittensory(~line 75), defines a volumes block withgittensory-data/gittensory-pg/gittensory-backups(~lines 1024-1040), Docker secretsgittensory_api_token/gittensory_mcp_tokenbacked by./secrets/gittensory_*.txt, a Tailscale hostnamegittensory(~line 845), andCOMPOSE_PROJECT_NAME: ${COMPOSE_PROJECT_NAME:-gittensory}(~line 783) — the latter is the effective container-name prefix self-hosters see indocker compose pssince there's no explicitcontainer_nameoverride.docker-compose.override.yml.examplerepeats the same service key (lines 1, 7, 24, 30, 33, 50), including an override stanzagittensory:at line 50, and referencessystemd/gittensory-docker-prune.*.example.caddy/Caddyfile(lines 1, 8, 12) reverse-proxies togittensory:8787by compose service name — if the service key renames without this file changing in the same commit, the proxy silently 502s against the wrong upstream host.systemd/gittensory-docker-prune.service.exampleand.timer.examplecarry the brand in their filenames, inDescription=Gittensory self-host Docker resource hygiene..., inWorkingDirectory=/opt/gittensory, inExecStart=/bin/sh /opt/gittensory/scripts/..., and in thesystemctl enable --now gittensory-docker-prune.timercommand operators copy straight out of the comments. Several shell scripts carry the same identifiers:scripts/deploy-selfhost-image.sh(SERVICE default),scripts/selfhost-init-secrets.sh(SECRET_FILES array:gittensory_api_token.txt,gittensory_mcp_token.txt),scripts/selfhost-update.sh(error message referencing "the gittensory git checkout"), andscripts/backup.sh(DB default/data/gittensory.sqlite, output filenamesgittensory-<ts>.dump/.sqlite). Adjacent to this,k8s/miner-deployment.yaml— a separate deployment artifact for gittensory-miner fleet mode — has the same pattern in its own scope: StatefulSet namegittensory-miner, labelapp.kubernetes.io/name: gittensory-miner,serviceName: gittensory-miner, imagegittensory-miner:latest, env varGITTENSORY_MINER_CONFIG_DIR, and secret namegittensory-miner-secrets.Area: Infra / Self-host
Proposal:
Open question (needs a maintainer decision before starting): Does the docker-compose service key itself (
gittensory:indocker-compose.ymlanddocker-compose.override.yml.example) get renamed, or does it stay as-is? Unlike the published image name in #4770, which is customer-facing, the compose service key is arguably an internal implementation detail — but renaming it is a breaking change for every self-hoster's owndocker compose exec gittensory ...muscle memory and for anydocker-compose.override.ymlcustomization they've already layered on top. Need a decision on which way this goes before touching the file.Once that's settled: rename the volumes, Docker secrets and their backing file paths, the Tailscale hostname, and the
COMPOSE_PROJECT_NAMEdefault indocker-compose.yml, carrying the same choice through todocker-compose.override.yml.example. If the compose service key does change, updatecaddy/Caddyfile'sreverse_proxytarget in the same commit so the proxy doesn't silently start 502ing against a stale upstream host. Rename thesystemd/gittensory-docker-prune.*.exampleunit files (and theirDescription=,WorkingDirectory=,ExecStart=, andsystemctl enable --now ...install commands), and update the identifiers threaded throughscripts/deploy-selfhost-image.sh,scripts/selfhost-init-secrets.sh,scripts/selfhost-update.sh, andscripts/backup.sh. Handlek8s/miner-deployment.yamlas its own pass since it's an adjacent, separate artifact (gittensory-miner fleet mode) rather than part of the core self-host compose stack.Deliverables:
docker-compose.ymlanddocker-compose.override.yml.examplereflecting whatever the compose-service-key decision lands on.caddy/Caddyfilereverse-proxy target, kept in lockstep with the compose service key.systemd/gittensory-docker-prune.service.example/.timer.examplefiles with updated internal contents and install-command comments.scripts/deploy-selfhost-image.sh,scripts/selfhost-init-secrets.sh,scripts/selfhost-update.sh, andscripts/backup.sh.k8s/miner-deployment.yaml(StatefulSet name, label, serviceName, image, env var, secret name).Acceptance criteria:
docker-compose.ymlanddocker-compose.override.yml.example.caddy/Caddyfile's reverse-proxy target matches the compose service name exactly — no 502s from a stale upstream host.systemctl enable --now ...commands.k8s/miner-deployment.yamlis internally consistent (name, labels, serviceName, image, env var, secret name all agree).Test scenarios:
docker compose upagainst the updated files and confirm the Caddy reverse proxy resolves to the running service without a 502.scripts/selfhost-init-secrets.shandscripts/backup.shend-to-end and confirm the secret files and backup output filenames use the new identifiers consistently.k8s/miner-deployment.yamlto a test cluster and confirm the StatefulSet, service, and secret all bind correctly under the renamed identifiers.Resources:
docker-compose.yml,docker-compose.override.yml.examplecaddy/Caddyfilesystemd/gittensory-docker-prune.service.example,systemd/gittensory-docker-prune.timer.examplescripts/deploy-selfhost-image.sh,scripts/selfhost-init-secrets.sh,scripts/selfhost-update.sh,scripts/backup.shk8s/miner-deployment.yamlBoundaries:
Part of #4761.