Many teams run services on EC2 instances, bare-metal servers, or simple VMs. They don't need Kubernetes, but they still want reliable, repeatable deployments with zero-downtime rollbacks. Tow fills this gap.

tow init                              # Auto-detect project → generate config
tow auto -e prod -m api-server        # Build → package → upload → deploy
tow rollback -e prod -m api-server    # Instant rollback

Why Tow?

| | Tow | Ansible | Capistrano | Kamal | |---|:---:|:---:|:---:|:---:| | Single binary, zero deps | Yes | Python + pip | Ruby + Bundler | Ruby + Docker | | Auto-detection | Yes | No | No | No | | No Docker required | Yes | Yes | Yes | No | | Multi-language native | 12 types | Manual | Ruby-first | Docker-only | | Built-in health checks | 4 types | Manual | Plugin | HTTP only | | Instant rollback | Symlink | Re-run playbook | Symlink | Container swap |

See the full comparison for detailed analysis.

What makes Tow different

Most deployment tools force you into their world. Ansible requires you to become a YAML/Jinja expert. Capistrano assumes you're a Ruby shop. Kamal demands Docker on every server. Tow works with what you already have.

Every other deployment tool starts with a blank config file you have to write from scratch. Tow scans your project and generates everything:

$ cd my-springboot-monorepo
$ tow init

✔ Detected: springboot (gradle, multi-module)
  Modules: api-server, batch-server, admin-server
  Excluded: common-lib, data-core (library modules)
  Framework: Spring Boot 3.x
✔ Generated tow.yaml
✔ Generated script/api-server/env.sh + server
✔ Generated script/batch-server/env.sh + server
✔ Generated script/admin-server/env.sh + server

It detects languages, frameworks (NestJS, FastAPI, Django, Flask, Next.js...), build tools, monorepo sub-modules, and even filters out library modules like -common or -core. Zero to deployable config in seconds.

Kamal is excellent — but it requires Docker on every target server. That's a non-starter for:

• JVM apps that already manage their own lifecycle and don't benefit from containerization
• Legacy infrastructure where installing Docker isn't an option
• Resource-constrained VMs where the Docker daemon overhead matters
• GPU workloads where Docker GPU passthrough adds complexity
• Regulated environments with container usage restrictions

Tow deploys directly to the OS. If you can SSH in, you can deploy.

Most deployment tools only handle application code. If you also run Kafka, Redis, or MongoDB on VMs, you need separate automation.

Tow manages everything through one interface:

tow auto -e prod -m api-server     # Spring Boot app
tow auto -e prod -m kafka          # Kafka broker
tow auto -e prod -m redis          # Redis server
tow status -e prod                  # Check everything

Same config file. Same commands. Same rollback mechanism.

Tow isn't a weekend project. It's the Go rewrite of deployment systems that ran in production across multiple companies — managing Spring Boot microservices, Kafka clusters, Redis, MongoDB, Prometheus, Grafana, and more.

Every feature exists because a real production incident demanded it:

• Deploy locking → Two developers deployed at the same time, caused inconsistent state
• Branch policies → Someone deployed a feature branch to production
• Health checks → Deploys "succeeded" but the app was crash-looping
• Hierarchical config → Server 1 needed different JVM settings than server 2

These aren't theoretical features. They're battle scars turned into safeguards.

Core Features

• Agentless — SSH is the only requirement on target servers
• Symlink-based atomic deployments — instant rollback via symlink switch
• Auto-detection — tow init detects your project type, framework, build tool, and monorepo modules
• 12 built-in module handlers — Spring Boot, Java, Node.js, Python, Go, Rust, Kafka, Redis, generic
• 4 health check types — HTTP, TCP, log pattern, custom command
• Hierarchical config — environment-level defaults with per-server overrides
• Branch policies — prevent deploying wrong branches to production
• Deploy locking — prevent concurrent deployments
• Parallel execution — deploy to multiple servers simultaneously
• Lifecycle hooks — pre/post build, deploy, start, stop

Installation

# Homebrew (macOS / Linux)
brew install neurosamAI/tap/tow

# npm
npm install -g @neurosamai/tow

# Go
go install github.com/neurosamAI/tow-cli/cmd/tow@latest

# Binary (macOS Apple Silicon)
curl -L https://github.com/neurosamAI/tow-cli/releases/latest/download/tow-darwin-arm64 -o tow
chmod +x tow && sudo mv tow /usr/local/bin/

Quick Start

# Initialize — auto-detects project type and generates tow.yaml
cd my-project
tow init

# Edit tow.yaml with your server IPs and SSH key paths
# Then setup remote servers and deploy
tow setup -e prod -m api-server
tow auto -e prod -m api-server

See the Getting Started guide for detailed instructions.

How Deployment Works

Local Machine                    Remote Server
─────────────                    ─────────────
1. build      →  compile/jar
2. package    →  tar.gz artifact
3. upload     →  ─── SCP ───→   ~/upload/module.tar.gz
4. install    →  ─── SSH ───→   deploy/20240626-101530/  (extract)
                                current → deploy/20240626-101530  (symlink)
5. stop/start →  ─── SSH ───→   bin/stop.sh → bin/start.sh

Rollback is instant — just switch the current symlink to a previous deployment directory.

Commands

| Command | Description | |---------|-------------| | tow init | Auto-detect project type and generate tow.yaml | | tow validate | Validate configuration file | | tow setup | Initialize remote server directories | | tow auto | Full pipeline: build → package → upload → install → restart | | tow deploy | Deploy pipeline: package → upload → install → restart | | tow start | Start a module | | tow stop | Stop a module | | tow restart | Restart a module | | tow status | Check module status (PID, uptime, memory) | | tow rollback | Switch to previous deployment | | tow logs | Stream remote logs with optional grep filter | | tow ssh | Execute commands on remote servers | | tow diff | Compare deployed vs local code | | tow config | Manage servers, modules, and assignments | | tow upload | Upload a file to target servers | | tow install | Install uploaded package (extract + symlink) | | tow login | SSH into a server | | tow unlock | Force release deploy lock | | tow list | List modules, environments, or deployment history | | tow cleanup | Remove old deployment directories | | tow download | Download files from remote servers | | tow provision | Provision a new server (timezone, JRE, tools) | | tow doctor | Pre-flight diagnostics | | tow mcp-server | Start MCP server for AI agent integration |

Advanced flags:

tow deploy --rolling          # Deploy one server at a time
tow auto --auto-rollback      # Auto-rollback if health check fails
tow auto -y                   # Skip production confirmation prompt
tow status -o json            # Machine-readable JSON output

See the full command reference for all flags and usage details.

Module Types

| Type | Default Build | Default Health Check | |------|---------------|---------------------| | springboot | gradlew bootJar | HTTP /actuator/health | | java | gradlew build | TCP port check | | node | npm ci && npm run build | TCP port check | | python | pip install -r requirements.txt | TCP port check | | go | go build | TCP port check | | rust | cargo build --release | TCP port check | | php | composer install | TCP port check | | ruby | bundle install | TCP port check | | dotnet | dotnet publish | TCP port check | | kotlin | ./gradlew build | TCP port check | | elixir | mix deps.get, compile, release | TCP port check | | generic | — | TCP port check |

Infrastructure services are supported via 35 bundled YAML plugins — Kafka, Redis, MySQL, PostgreSQL, MongoDB, Elasticsearch, ZooKeeper, Nginx, Prometheus, Grafana, Loki, Vault, Jenkins, and more.

Community plugins can be installed from GitHub:

tow plugin add someuser/tow-plugin-mssql          # GitHub repo
tow plugin add myorg/infra-plugins/oracle.yaml     # specific file
tow plugin add https://example.com/custom.yaml     # any URL
tow plugin list                                     # list all (bundled + external)

Documentation

Full documentation is available at tow-cli.neurosam.ai:

• Getting Started — Install and deploy in 5 minutes
• Architecture — How Tow works under the hood
• Configuration — Full tow.yaml reference
• Commands — CLI reference
• Security — Secrets management and SSH hardening
• Examples — Real-world deployment scenarios
• Comparison — Tow vs. Ansible, Capistrano, Kamal, and more

AI Agent Integration

Tow is the first deployment tool with native AI agent support.

MCP Server (Claude, Cursor, Windsurf)

{
  "mcpServers": {
    "tow": {
      "command": "tow",
      "args": ["mcp-server"],
      "env": { "TOW_CONFIG": "./tow.yaml" }
    }
  }
}

Then ask your AI assistant: "Check the status of api-server in prod" or "Roll back the API".

Claude Code Skill

Copy integrations/claude-skill/tow-deploy.md to .claude/skills/ in your project.

VS Code Extension

See integrations/vscode/ — sidebar UI with environments, modules, and deployment controls.

Current Status

Tow is at v0.2.0 — it's functional and actively developed, but early-stage. Here's what to expect:

What works well:

• Project auto-detection and config generation (10 languages, 40+ frameworks, 35 infrastructure plugins)
• Full deployment pipeline over SSH (build → package → upload → install → restart)
• Symlink-based instant rollback
• Parallel execution, rolling deploy, auto-rollback
• Health checks, deploy locking, branch policies
• YAML plugin system for infrastructure services

Known limitations (v0.1.0):

• No resume for interrupted large file uploads — failed uploads must restart from scratch
• tow init generates a config skeleton — you still need to edit server IPs and SSH key paths
• No blue-green deployment strategy yet (rolling deploy is supported)
• IDE plugins (VS Code, JetBrains) are functional but early-stage
• Test coverage is ~42% overall (87-100% for pure logic, lower for SSH-dependent code pending interface refactoring)

Roadmap to v1.0:

• SSH interface abstraction for testability (target: 80%+ coverage)
• Blue-green deployment strategy
• Web dashboard for deployment status
• Config encryption for sensitive values

If you hit an issue, please open a GitHub issue. We take bug reports seriously.

Contributing

Contributions are welcome! See CONTRIBUTING.md for guidelines.

License

MIT — Copyright (c) 2026-present Murry Jeong (comchangs) and neurosam.AI (Neurosam AI Inc.)