Soft Serve

Self-hosted Git hosting, honestly reviewed. Built by the people behind Bubble Tea and Glow — no marketing fluff, just what you get when you run it.

TL;DR

• What it is: A minimal, self-hostable Git server from Charmbracelet — MIT-licensed, single binary, with a polished SSH-accessible terminal UI you can browse from any SSH client [README].
• Who it’s for: Developer-first teams or solo engineers who want private Git hosting without GitHub’s per-seat costs and don’t need a web interface, issue tracker, or CI/CD pipeline.
• Cost savings: GitHub Team costs $4/user/month (private repos). GitLab Premium runs $29/user/month. Soft Serve self-hosted runs on a $5–10/month VPS with no per-seat fees [README].
• Key strength: Single-binary deployment, genuinely the simplest path to private Git hosting. The SSH TUI — browse files, commits, and repos from your terminal — is something no other self-hosted Git server does.
• Key weakness: No web interface, no issue tracker, no pull request workflow, no CI/CD. This is not a GitHub replacement. It’s a Git server that happens to have a beautiful terminal UI. Non-technical users will find nothing here to use [README][1].

---

What is Soft Serve

Soft Serve is a self-hosted Git server built by Charmbracelet — the same team behind the Bubble Tea TUI framework, Glow (the terminal Markdown reader), and Lipgloss. It’s MIT-licensed, written in Go, and distributed as a single binary called soft [README].

The pitch is narrow and accurate: “A tasty, self-hostable Git server for the command line.” It is not trying to clone GitHub. It doesn’t have an issue tracker, a pull request review UI, a wiki, a project board, or a web interface for browsing code in a browser. What it has is a rich SSH-accessible TUI — log in over SSH and you get a full-screen terminal application for browsing repos, files, and commits. Clone over SSH, HTTP, or the Git protocol. Manage repos and users through SSH commands. [README]

The project sits at 6,721 GitHub stars with 207 forks. It’s available through most major package managers — Homebrew, apt, pacman, nix, winget — and as a Docker image and Go module. The FreeBSD community packages it in their ports tree (currently at version 0.7.6) [1][README].

What makes Soft Serve categorically different from Gitea, Forgejo, and GitLab CE is that it makes no attempt to build a web application. Every user-facing interaction runs through SSH. You ssh git.charm.sh to see their live demo, then ssh your-server -t repo-name to jump into a specific repo. You push, pull, and clone using standard git commands. The server handles authentication via SSH public keys — no passwords, no OAuth flows, no email verification [README].

---

Why people choose it

Third-party review coverage of Soft Serve as a Git server is sparse — the tool is niche by design and its target audience (engineers who prefer CLI tooling) writes less on review aggregators than the Zapier-replacement crowd. What can be synthesized from packaging maintainer notes and the project’s own documentation is a consistent pattern: people choose it for three reasons.

Simplicity of operation. soft serve starts the server. That’s the entire setup path. No database configuration wizard, no web UI bootstrap, no admin account creation flow. The first-run experience is two steps: set your SSH public key in an environment variable, start the binary [README]. The FreeBSD port maintainer noted a significant migration path was required in the 0.4.x → 0.5.x upgrade (the config repository model was replaced by a YAML config file), but since 0.5.0 the config model has been stable [1].

SSH-native workflow. For teams that already use SSH keys everywhere — deploy keys, server access, dotfile management — Soft Serve fits without adding a new auth model. No new username/password credentials to manage. No OAuth app to register. Every collaborator’s existing SSH public key becomes their credential [README].

Charmbracelet quality. The team has a demonstrated track record of building terminal tools that are genuinely well-designed, not just functional. The TUI (browse repos, view file trees with syntax highlighting, read commit history) is meaningfully nicer than interacting with a bare git daemon. You can print any file with syntax highlighting and line numbers directly over SSH: ssh your-server repo blob repo-name path/to/file.go -c -l [README].

---

Features: what it actually does

Based on the README:

Core Git hosting:

• Clone repos over SSH, HTTP, or Git protocol [README]
• Create repos on demand with git push — no pre-registration step [README]
• Git LFS support via both HTTP and SSH backends [README]
• Webhooks for repo events [README]
• PostgreSQL or SQLite as the backing database [README]

The SSH TUI:

• Full-screen terminal UI accessible over SSH — browse repos, files, commit history [README]
• Print files with optional syntax highlighting and line numbers [README]
• Directory tree view for any repo [README]
• Jump directly to a specific repo: ssh server -t repo-name [README]
• Also works locally: soft browse [directory] or soft inside a git repo [README]

Access control:

• SSH public key authentication — no passwords [README]
• Allow or disallow anonymous access per server [README]
• Public or private repos [README]
• Add collaborators by SSH public key [README]
• User access tokens for programmatic access [README]
• Admin setup via SOFT_SERVE_INITIAL_ADMIN_KEYS environment variable [README]

Operations:

• Single binary deployment [README]
• Systemd service unit included in apt/yum packages [1]
• Docker image available [README]
• YAML configuration file (generated on first run) [README]
• Custom data path via SOFT_SERVE_DATA_PATH env var [README]

What it doesn’t have:

• Web interface
• Issue tracker
• Pull request / code review workflow
• CI/CD pipeline
• Wiki or documentation hosting
• LDAP / SAML / SSO
• Email notifications

---

Pricing: self-hosted math

Soft Serve has no SaaS offering and no commercial license tier. The software is free (MIT) and you host it yourself. The only cost is infrastructure.

Soft Serve self-hosted:

• Software: $0 [README]
• VPS to run it: $5–10/month (Hetzner CX21, Contabo, DigitalOcean Droplet)
• Storage for repos: included in VPS or attached block storage at ~$0.10/GB/month

GitHub for comparison:

• Free: unlimited public repos, private repos limited to 3 collaborators on the free tier for organizations
• GitHub Team: $4/user/month — unlimited private repos, 3,000 CI/CD minutes/month
• GitHub Enterprise: $21/user/month

GitLab for comparison:

• Free SaaS tier: 5GB storage, 400 CI/CD minutes/month
• Premium: $29/user/month
• Ultimate: $99/user/month

Concrete math for a 5-person engineering team:

On GitHub Team, a 5-person team pays $4 × 5 = $20/month, or $240/year. On GitLab Premium, that’s $29 × 5 = $145/month, or $1,740/year. On Soft Serve with a $6/month Hetzner VPS, that’s $72/year regardless of team size — though you lose issue tracking, PR workflows, and CI/CD minutes entirely.

The honest framing: Soft Serve is not a cost-optimization for most teams because it doesn’t replace all the things you use GitHub for. If you only need private repo hosting and SSH-based collaboration, the savings are real. If you also need CI/CD, issues, and PRs, you’ll pay for those separately anyway.

---

Deployment reality check

This is genuinely one of the simpler self-hosted tool deployments available.

Minimum setup:

1. Install the soft binary (one command via brew/apt/Docker)
2. Set SOFT_SERVE_INITIAL_ADMIN_KEYS to your SSH public key
3. Run soft serve

That’s a working Git server. For production:

• A Linux VPS (1 CPU, 512MB RAM is enough for small teams; 1–2GB recommended with LFS)
• A domain pointed at your server
• A reverse proxy (Caddy or nginx) if you want HTTPS for HTTP clones
• Systemd unit (included in apt/yum packages) for auto-restart [1]
• SQLite (default, zero-config) or PostgreSQL for larger installations [README]

What can go sideways:

The most notable rough edge is the 0.4.x → 0.5.x migration, which required moving from a config-repo-based system to a YAML file. The FreeBSD port maintainers explicitly documented this in their UPDATING notes, and the migration had to be incorporated into the rc.d script [1]. If you’re upgrading from a very old installation, review the v0.5.0 release notes before running the upgrade.

Anonymous access configuration requires understanding the YAML config structure — the default config is self-explanatory, but it’s not a UI wizard. Anyone without comfort editing YAML will struggle.

HTTP clone support requires a reverse proxy setup. The SSH path works out of the box; HTTP requires more server configuration.

Realistic setup time for an engineer: 15–30 minutes to a working server on a fresh VPS, including domain and SSL. For someone who’s never run a Linux server: this is not the right tool — there’s no web UI to guide non-technical users through repo creation or access management.

---

Pros and cons

Pros

• Genuinely minimal. Single binary, zero dependencies beyond git. Starts in one command. No Docker-compose file with 6 services [README].
• MIT licensed. No usage restrictions, no commercial agreement, no seat limits in the license. Self-host for a 200-person team under the same terms as a solo dev [README].
• SSH TUI is unique. No other self-hosted Git server offers this. Browse repos, files, and commits in a polished terminal UI from any SSH client. Genuinely useful for dev teams that live in the terminal [README].
• Charmbracelet polish. The team’s track record on TUI tooling (Bubble Tea, Glow, Lipgloss) carries over. This isn’t a barebones git daemon thrown in a binary.
• Multiple clone protocols. SSH, HTTP, and native Git protocol all supported. LFS works over both SSH and HTTP backends [README].
• On-demand repo creation. git push to a new repo URL creates it automatically. No pre-registration step [README].
• Webhooks included. Repo events can trigger external services [README].
• Package manager support. apt, brew, pacman, nix, winget, Docker, go install — pick your ecosystem [README][1].
• FreeBSD first-class. Maintained in the FreeBSD ports tree, regularly updated [1].

Cons

• No web interface. If any member of your team is not comfortable with SSH, they cannot use Soft Serve. There is no browser-based alternative path [README].
• No pull request workflow. Code review requires external tooling or email. This is a hard blocker for many teams [README].
• No issue tracker. Bugs, features, and tasks live elsewhere — Linear, GitHub Issues, Notion, whatever you already use [README].
• No CI/CD. You’ll run Jenkins, Woodpecker, or Forgejo Actions separately. Soft Serve does support webhooks so you can trigger external CI, but nothing is bundled [README].
• No SSO/LDAP. User management is purely SSH public keys. Fine for engineers, impossible for non-technical collaborators [README].
• No web-based code browsing. The SSH TUI is beautiful, but some team members will want to link to a file in a browser. That doesn’t exist here [README].
• Small community. 6,721 stars is healthy for a niche tool, but it’s not the Gitea/Forgejo ecosystem. Third-party documentation is sparse. Stack Overflow coverage is minimal.
• Migration path history. The 0.4.x → 0.5.x breaking change required explicit migration steps [1]. Not a current problem, but signals that major version upgrades may require attention.

---

Who should use this / who shouldn’t

Use Soft Serve if:

• You’re a solo developer or small engineering team that wants private Git hosting with zero per-seat cost.
• Everyone who needs repo access is comfortable with SSH and the command line.
• You want Git hosting without the overhead of maintaining a full Gitea/GitLab instance.
• Your code review process lives in a separate tool (GitHub for open source, Linear for issues) and you just need a private remote.
• You value the SSH TUI — checking code, exploring file trees, reading commits without leaving the terminal.

Skip it (use Forgejo or Gitea instead) if:

• Anyone on your team needs a browser to access repos.
• You want pull requests, code review, or an issue tracker on the same server.
• You need self-hosted CI/CD tightly integrated with your Git server.
• You’re migrating off GitHub and want feature parity in self-hosted form.

Skip it (stay on GitHub Free/Team) if:

• Your team already fits in GitHub’s free tier or the per-seat cost is acceptable.
• You rely on GitHub Actions, GitHub Packages, or the GitHub API surface.
• Any of your collaborators are non-technical.

Skip it (use GitLab CE) if:

• You need the full DevOps platform: CI/CD, container registry, security scanning, and wiki — all self-hosted.
• Your organization requires SSO/LDAP integration.
• You have the infrastructure resources to run GitLab (it’s significantly heavier than Soft Serve).

---

Alternatives worth considering

• Forgejo — the community fork of Gitea after the Gitea governance controversy. Full web UI, pull requests, issues, CI/CD (Forgejo Actions), multiple auth providers. The default choice for most teams moving off GitHub self-hosted. More complex to operate than Soft Serve but does everything Soft Serve doesn’t.
• Gitea — the original. Same feature set as Forgejo, company-backed. Pick Forgejo if community governance matters to you.
• Gogs — the minimal predecessor to Gitea. Lighter resource footprint, similar web UI, much smaller development team. Worth considering if you want a web-based Git server with minimal resource usage.
• GitLab CE — the enterprise-grade option. Complete DevOps platform. Requires serious infrastructure (4–8GB RAM minimum). Only worth considering if you need the full feature set.
• cgit — bare-bones web interface for git repositories. No user management, no SSH TUI — just browsable commit history in HTML. For public read-only mirrors, not private hosting.

For most teams leaving GitHub and wanting like-for-like feature replacement: Forgejo is the realistic choice. For teams that specifically want minimal, CLI-native private Git hosting and don’t need a web UI: Soft Serve has no real competition.

---

Bottom line

Soft Serve fills exactly one slot in the self-hosted Git landscape: minimal private Git hosting for developer teams who work entirely in the terminal. It does that slot very well. The single-binary deployment, the MIT license with no seat limits, and the SSH TUI set it apart from everything else in the category. But it’s honest about what it isn’t — there’s no web UI, no issue tracker, no pull request workflow, and no CI/CD integration. For a non-technical founder who wants to “escape expensive SaaS,” Soft Serve is not the answer; Forgejo is. For a three-person engineering team that wants private repos, costs under control, and a clean SSH-based workflow without maintaining a GitLab instance, Soft Serve is the cleanest possible solution.

---

Sources

1. FreshPorts — devel/soft-serve: Self-hosted Git server for the command line (FreeBSD ports, version 0.7.6_17, maintainer ashish@FreeBSD.org). https://www.freshports.org/devel/soft-serve/

Note: Third-party sources [2], [3], and [4] as provided in the source inputs — a cozy mystery novel review and two articles about soft-serve ice cream sales — are not related to the Soft Serve Git server and were not used in this review. Primary sourcing relies on the README, GitHub repository, and FreeBSD ports documentation.

Primary sources:

• GitHub repository and README: https://github.com/charmbracelet/soft-serve (6,721 stars, MIT license)
• Charm apt repository and package distribution: https://repo.charm.sh/
• FreeBSD ports upgrade notes (v0.5.0 migration): https://www.freshports.org/devel/soft-serve/