---
name: cc-ci-server-update
description: (Delegates) Update the cc-ci CI server host to the latest nixpkgs — which, since 2026-09-07, is the SAME machine as the orchestrator, built from the cc-ci-orchestrator flake. This skill only forwards to /cc-ci-orchestrator-update; it no longer bumps or rebuilds the cc-ci repo's own flake, because that standalone `#cc-ci` target would replace the combined host config. Invoke as /cc-ci-server-update.
---

# cc-ci-server-update → `/cc-ci-orchestrator-update`

There is no separate CI-server host any more. The CI server runs on the cc-ci host
(195.201.88.249) together with the orchestrator, from **one** flake:
`recipe-maintainers/cc-ci-orchestrator` `#cc-ci`, which imports the cc-ci repo's
`nixosModules.cc-ci-server` and makes that input follow its own nixpkgs and sops-nix.

**Run `/cc-ci-orchestrator-update`.** It updates nixpkgs, sops-nix AND the cc-ci input, tests,
health-checks (the CI server's swarm, front doors, sops, acme-dns — the checks this skill used to
do) and switches, via the host's own weekly auto-update unit.

Do **not** do what the old version of this skill did:
- do not bump `flake.lock` in the cc-ci repo expecting it to change the live host (it cannot — the
  host follows the orchestrator flake's inputs; cc-ci's lock only matters for the standalone
  `#cc-ci` target, which nothing deploys);
- do not run `nixos-rebuild switch --flake /etc/cc-ci#cc-ci` or `...#cc-ci-hetzner` on the host —
  that is the standalone-server configuration and would take the orchestrator half down.

If what you actually wanted is "the host should run cc-ci `main` as of now" (a harness or test
change), that is `/cc-ci-orchestrator-update --cc-ci-only`.