Atlassian Data Center As A Torque Stack

Torque cuts DevOps tool sprawl and restores development velocity for agentic delivery flows.

The starting point was intentionally ordinary: the public Atlassian Data Center Helm charts, a pair of Linux hosts, and a need to prove that a real multi-application stack could be shipped without falling back to a hand-written runbook. The target stack was not a toy. It included Jira, Confluence, Bitbucket, Bamboo, Crowd, a Bamboo agent, PostgreSQL backing databases, and shared storage for the products that need it. That mix is useful because it behaves like enterprise software usually behaves: stateful services, chart defaults, long startup times, product setup screens, secret material, persistent volumes, and several places where a deployment tool has to show its work.

The first pass was direct. I installed k3s across the two hosts, prepared NFS-backed shared storage, pulled the Atlassian charts from atlassian/data-center-helm-charts, and used Torque to apply each release. That step mattered because it kept the baseline boring. Before turning the setup into a stack, I wanted to know the charts rendered, the services came up, the NodePorts were reachable, and the product pods could get to their databases. Torque was already useful there because the apply path gave me a consistent release loop and verifier output instead of a collection of one-off Helm commands.

After the first successful deploy, I converted the release commands into a Torque stack. The stack made the dependency order explicit: storage first, prerequisite databases and Kubernetes Secrets next, application releases after that, and the Bamboo agent last. This is where Torque becomes more than a wrapper around Helm. The stack file gives the whole system a shape that can be reviewed, replayed, resumed, and debugged. If a downstream release fails, the operator does not need to reconstruct which values file or namespace was used. The stack has that context.

The next problem was secrets. Plaintext database passwords in values files are exactly the kind of shortcut that becomes permanent if nobody removes it early. I added a local Torque secret provider and changed the prerequisite values to use secret://local/... references for the database passwords and Bamboo agent security token. One practical lesson came out of that work: secret resolution belongs in the supplied values path, not buried in a chart default file that the deploy tool does not own. Moving the references into the explicit values file made the behavior obvious, and the generated Kubernetes Secrets were then checked to confirm that the cluster received resolved values instead of literal secret:// strings.

Verifier as a hard gate. With the stack and secret provider in place, the deployment path became stricter. I used verifier --mode block --fail-on high, generated per-release evidence, and required that evidence before apply. The actual apply path used torque apply --require-verified with --drift-guard, so the rollout had to match the verified plan instead of silently accepting a changed render. This turns "I think this is safe" into "this exact render passed these checks." Helmer was used beside that flow to produce HTML plans for review. In practice, this is the part that makes a Torque case study different from a normal install note. The output is not just "the pods are running"; it is a bundle of stack files, rendered plans, verifier reports, and apply evidence that another operator can inspect later.

The newer proof features push that same idea past the initial rollout. torque apply simulate can create a Live Apply Twin before a risky change touches the cluster. After the change, torque guardian diff compares that simulation proof with live Kubernetes objects, managed-field owners, events, aftercare state, and secret-boundary evidence. If a product pod later fails because an image cannot be pulled, a webhook mutates a field, a ConfigMap starts carrying secret-like data, or an operator edits a live object by hand, Guardian turns the runtime difference into evidence instead of guesswork. torque incident capture and torque incident replay then make the failure portable: resource state, events, bounded logs, root cause, and PR-ready notes can be reviewed without keeping access to the original terminal. The newest layer, torque contract synthesize and torque contract test, converts those incident and drift proofs into recurrence rules. For an Atlassian stack, that means the next deploy can prove "no image pull failure, no secret-boundary regression, no unexplained managed-field owner, and no failed aftercare" with a machine-checkable contract instead of a Slack memory.

torque release promote ./reports/proof.graph.json \
  --strategy canary \
  --steps 5,25,50,100 \
  --analysis-window 5m \
  --slo ./reports/slo.yaml \
  --rollback-on-fail \
  --key .torque/stack/keys/ed25519.json \
  --out-dir ./reports/promote-canary

torque release promote ./reports/proof.graph.json \
  --strategy blue-green \
  --preview \
  --smoke ./reports/smoke.json \
  --switch-traffic \
  --key .torque/stack/keys/ed25519.json \
  --out-dir ./reports/promote-blue-green

torque release promote ./reports/proof.graph.json \
  --strategy blue-green \
  --preview --smoke ./reports/smoke.json --switch-traffic \
  --provider file --state-out ./reports/traffic-state.json \
  --execute --yes --format json

I also built custom images for the same stack. The goal was not to fork Atlassian products or bake configuration into images. The goal was to prove that Torque could own the image build step as part of the same delivery story. The Dockerfiles pinned the upstream Atlassian, PostgreSQL, and NFS provisioner bases by digest, added only small operational changes where useful, and ran through Torque build with secret scanning enabled. The Bamboo agent image is the clearest example: it keeps the upstream agent base but adds common diagnostic and CI tools such as curl, git, jq, openssh-client, tar, and unzip. The built OCI layouts were imported into k3s containerd on both nodes and then referenced from the stack values as torque.local/atlassian/... images.

There were two useful debugging moments. First, generated reports showed that some chart warnings were acceptable for this lab only because the verifier gate was set to fail on high and above, not because all findings should be ignored in production. Second, one image build tripped a secret scanner false positive on packaged OpenSSH binaries inside the Bitbucket image. That is exactly the kind of case where policy should be adjustable but not disabled. I added a small scanner rules file that kept build argument and log scanning strict while avoiding that OCI-content false positive.

Torque logs as an operational graph. The useful log view was not just "show me this pod." It was logs by stack dependency, active ReplicaSet, readiness condition, and event context. The same command family handled dependency-aware context with --deps, namespace-wide unhealthy pods with --condition, Kubernetes events with --events, active rollouts with --deploy-mode active, and durable handoff evidence with --capture. That is especially strong for agents because they can inspect failure context from the stack graph without guessing Kubernetes object names first.

torque logs deploy/jira -n atlassian --events --tail 80 --highlight 'ERROR|FATAL|Failed|ImagePull|BackOff'

torque logs deploy/bamboo-agent -n atlassian --deploy-mode active --events --tail 60 --highlight 'FATAL|fingerprint|setup|redirect'

torque logs -n atlassian --condition ready=false --events --tail 30 --exclude 'healthcheck|heartbeat'

torque logs jira -n atlassian --config ./stack.yaml --deps --events --tail 60

torque logs deploy/bamboo-agent -n atlassian --events --tail 200 --capture ./reports/logs/bamboo-agent.sqlite

The result is a repeatable path for a difficult stack. Atlassian first-run screens and license entry still exist, and Bamboo agents still depend on Bamboo being initialized. Torque does not remove product lifecycle steps. What it does is make the infrastructure side reviewable: the charts are rendered through one path, secrets come from a provider, verifier decides whether the release can proceed, drift guard protects the apply, Helmer produces readable plan evidence, and image builds can be attached to the same operational story. That is the practical value: less magic, more files, and a deployment that can be replayed without depending on terminal memory.

Agent-native execution. This is also why Torque is perfect for working with agentic systems. Codex, Claude, Gemini, CI, or humans should not shell-script DevOps from scratch; they should operate the same Torque workflows through an MCP or API surface. That gives the workflow durable jobs, resumable steps, an audit trail, permissions, approvals, verifier evidence, and log context instead of an unreviewable terminal transcript. The final capture shows Codex using Torque on the same Atlassian deployment.