Gone in 60 Seconds

Modern CI/CD became needlessly complex and needlessly centralized. It drifted into the same kind of heavyweight workflow that IDEs had before agentic AI showed that a better pattern is often to give the model a real tool instead of burying it under another giant control plane.

That is what Torque is doing for delivery. It simplifies the process and moves it toward proof-based deploys, but that does not mean the underlying system is simple. It means complexity is handled inside typed resources, verification paths, and audit artifacts instead of being sprayed across controllers, YAML glue, CronJobs, sidecars, and runbooks.

So if you want to bring up a Kafka cluster, GitLab, or Keycloak in a few minutes, the point is not only that one command starts the lab. The point is that the command sits on top of a graph that knows what it is doing.

A stackfile in Torque is a DAG that can deploy a Postgres cluster, S3, and RDS on its own; back up Postgres to S3; delete the local dump; restore from S3 into RDS; verify the database in RDS; and then remove the AWS, Docker, and VM resources with torque stack delete.

Not Another Command Runner

Ansible and Salt were written in a dynamic language, Python, and their model historically grew out of command runners: execute a module, return a log, and show changed=true/false. Salt has a message bus, but it is still mostly transport for launching commands and collecting the result.

Torque is fundamentally different: a typed runtime where every resource knows its own semantics, plan, verification, and audit path. Torque is written in Go.

Ansible and Salt run commands. Torque manages system state.

Everything In One Stackfile

Everything Torque needs can live in a single stackfile:

kind: postgres.backup.run
kind: postgres.backup.verify
kind: postgres.restore.drill
kind: postgres.replication.verify
kind: postgres.role.ensure
kind: postgres.grant.ensure

To get a similar result in Kubernetes, you usually have to assemble a thousand components: an operator, a CronJob, a sidecar, a secret manager, object storage glue, a restore job, monitoring, runbooks, and audit logs.

This is not just pg_dump.

Torque has to prove that the database was live, which backup was created, what SHA256 it has, where the S3 object was uploaded, whether the restore works, and whether SQL verification passed.

Works With Jenkins Too

Torque is not asking you to rip out the CI/CD you already have. We proved that by booting Jenkins inside a Firecracker VM, pointing it at a second Firecracker PostgreSQL lab, and running a backup-only Torque stack from a plain job. Jenkins stayed the scheduler and artifact store. Torque handled the part Jenkins is bad at: typed planning, backup execution, verification, audit, and export.

The job was parameterized through an env file instead of hardcoded pipeline glue. That file carried the lab host, SSH identity path, PostgreSQL primary address, and local tunnel settings. Jenkins triggered one script, Torque planned the stack, executed postgres.backup.run and postgres.backup.verify, and archived proof instead of just printing logs. In the live run, Jenkins build #3 produced a dump at runtime/backups/torque-firecracker-direct.dump with SHA256 a7cd7639e2eeac09b18382d7356eb74cedd89fa1727bfc20f3bd50bbe1c9eb65. The build artifacts included the dump, manifest, catalog, summary, audit output, and export bundle. That is the practical point: keep Jenkins, GitLab CI, or another runner as the entrypoint, and let Torque become the typed engine underneath.

pipeline {
  agent any

  stages {
    stage('Torque PostgreSQL Backup') {
      steps {
        writeFile file: 'ci/jenkins/jenkins-job.env', text: '''
TORQUE_JENKINS_SKIP_BASE_STACK=1
TORQUE_LAB_SSH=ssh://root@141.105.65.227
TORQUE_LAB_SSH_IDENTITY=/var/lib/jenkins/torque/keys/host_ed25519
TORQUE_FIRECRACKER_PG_PRIMARY_HOST=172.31.240.10
TORQUE_JENKINS_PG_LOCAL_PORT=15432
TORQUE_JENKINS_PG_CONTROL=/tmp/torque-jenkins-pg.ctl
TORQUE_JENKINS_BACKUP_RUNTIME=runtime
'''.stripIndent()

        sh '''
          set -euo pipefail
          bash testdata/stack/e2e/33-firecracker-jenkins-postgres-backup/jenkins-job.sh \
            ci/jenkins/jenkins-job.env
        '''
      }
    }
  }

  post {
    always {
      archiveArtifacts artifacts: 'evidence/**,torque-firecracker-postgres-backup-evidence.tgz', fingerprint: true
    }
  }
}

What Comes Next

Soon Torque will be able to manage a fleet of 10,000 machines. Ansible does not handle that, even in the paid Red Hat distribution. Existing Ansible automation will be easy to move into a Torque stack, and Terraform or OpenTofu providers will be transformable into Torque adapters with one command, because everything the community has already built should remain usable.

The goal is simple: keep the ecosystem, but replace log scraping and glue scripts with a typed, auditable, high-speed runtime.