Road to Bastion Deploy

Status: 1.1.0 includes a deploy panel. This note is the original plan. Git-push rollback restores a previous revision, not a whole server.

If you’ve used Bastion Terminal for any length of time, you’ve probably hit the same small frustration: I’m already SSH’d into my server, I have my Git history on my laptop, why am I opening another app to deploy?

That’s the bet behind Bastion Deploy: the SSH workspace you already have is the right place to deploy from. The terminal, the hosts, the Plan Card are the same surface. We just have to finish the product.

This post is the high-level plan. The site copy is on the deploy docs.

What we’re not building

Before the wave list, the list of things we are explicitly not building:

• A GitHub replacement. No pull requests, no code review, no Issues.
• A CI/CD SaaS. No hosted runners, no per-minute billing, no vendor-managed build cache.
• A second deploy product. Deploy lives in the main Bastion shell, not a separate app.

We considered each of these and rejected them. The job to be done is “push from my machine to my server, with version control and approval gates built in.” That’s the scope.

The four waves

D0: Profiles and status

The minimum useful version. Link a local project to a host and a remote path. Show the local commit vs the server-deployed revision. Show a diff. No sync, no deploy. Just status.

This is the wave that proves the architecture. The local Git reader, the remote revision reader, and the deploy profile storage all land here.

Exit criteria: given a local repo and an SSH host, “Bastion deploy status” shows the right answer and a one-line diff summary.

D1: Sync MVP

The first wave that actually moves bytes. rsync/scp from the local project to the remote path, with the excludes list honored. A deploy audit log row per sync. The Plan Card is wired up but defaults to “Approve all” for non-production targets.

Exit criteria: a one-shot rsync deploy lands on a target, the audit log records it, and a Plan Card appears for production targets.

Dependency note: D1 can ship with rsync via local shell before v1.1 SFTP. SFTP improves browse and partial sync UX but is not strictly required.

D2: Git-native

The wave that makes the product feel right. Bare repo on the server, local git push over SSH, a post-receive hook that triggers the deploy. Rollback by reverting the server’s HEAD. The Plan Card becomes the standard mutation gate.

Exit criteria: a single git push from the laptop results in a deploy Plan Card on the Bastion side, and an approved deploy puts the new commit on the server with the audit log recording every step.

D3: Polish and AI

The wave that closes the loop with Bastion AI. A “Deploy” mode in the AI assistant that uses the same Plan Card pipeline. Health checks after deploy. Workspace bindings so a workspace like “Production” restores the linked projects, the open tabs, and the deploy history together.

Exit criteria: the AI can take a deploy instruction in natural language, produce a Plan Card, and the workspace restore on relaunch brings deploy state back.

The non-negotiables

Some of these are also the non-negotiables for Bastion AI. They’re repeated here because they’re the spine of the product.

1. Local-first. Deploy profiles, history, and diffs stay on device. No Bastion cloud account required.
2. No secret leakage. .env, keys, and credentials in sync paths are excluded by default. AI diff previews are redacted.
3. Trust before mutate. Sync, build, restart, and hook installs require explicit approval, either as a batch or step by step.
4. Reuse v1 surfaces. Hosts, SSH sessions, snippets, keychain, SQLite, Plan Card. No second deploy product.
5. Phase gates. No starting the next wave until the current wave’s exit criteria pass.
6. No silent production deploy. Production targets require stronger gates. The default for prod tags is step-by-step.

What’s in scope for the broader platform

Deploy is one pillar of a much larger platform ambition. The long-term platform diagram shows where Docker, K8s, databases, cloud providers, monitoring, and runbooks will eventually sit. The D-waves are deliberately scoped to the smallest useful thing so that we can ship, learn, and adjust.

We’re not committing to a date for D0 yet. When we are, the roadmap page will reflect it.

How to follow along

• The Bastion Deploy feature page. Marketing version.
• The Deploy docs. Long-form reference, including the architecture diagram. Deploy is in the public 1.1.0 release. Git-push rollback restores a previous revision for that profile.

The Linux installer is on the download page.