Soft Serve: A Git Server That Lives Entirely in Your Terminal

A Git Server for People Who Live in the Terminal

Soft Serve solves a specific problem: managing Git repositories without leaving the command line. It is a self-hostable Git server that you operate entirely over SSH. The server exposes a TUI that you can navigate with arrow keys, and you can clone, push, and browse repositories through standard Git commands. The project is from Charmbracelet, the same team behind the popular Bubble Tea TUI framework, so the terminal interface is polished. The intended user is someone who already uses SSH daily and finds web-based Git hosts like GitHub or GitLab to be overkill or too heavy. It is not for teams that rely on code review workflows, issue trackers, or a graphical browser interface.

How Soft Serve Works: SSH, HTTP, and Git Protocol

The server runs as a single binary called `soft`. When you start it with `soft serve`, it creates a `data` directory that stores repositories, SSH keys, and a database. The server listens on multiple protocols: SSH for the TUI and Git operations, HTTP for cloning, and the Git protocol. The SSH endpoint is the primary interface. You can connect to the server with `ssh git.charm.sh` to see a demo, or to your own server to browse repositories. The TUI lets you navigate repos, files, and commits. You can also issue commands directly over SSH, such as `ssh git.charm.sh repo tree soft-serve` to print a directory tree, or `ssh git.charm.sh repo blob soft-serve cmd/soft/main.go -c -l` to print a file with syntax highlighting and line numbers. This command-line access is a distinct advantage over web-based servers, because it allows scripting and automation without scraping HTML.

Getting Started: From Binary to Running Server

Installation is straightforward. You can use a package manager: `brew install charmbracelet/tap/soft-serve` on macOS or Linux, `winget install charmbracelet.soft-serve` on Windows, `pacman -S soft-serve` on Arch, or `nix-env -iA nixpkgs.soft-serve` on Nix. Debian and Fedora repositories are also available. Or you can install with Go: `go install github.com/charmbracelet/soft-serve/cmd/soft@latest`. Once installed, you run `soft serve`. On first boot, you must set the `SOFT_SERVE_INITIAL_ADMIN_KEYS` environment variable to your SSH public key, so the server can create an admin user. The server then generates a `config.yaml` file in the data directory. You can override settings with environment variables prefixed with `SOFT_SERVE_`, such as `SOFT_SERVE_SSH_LISTEN_ADDR` for the SSH listen address or `SOFT_SERVE_DATA_PATH` to change where data is stored. There is also `SOFT_SERVE_DEFAULT_REPO` to create a repository on boot, which the README notes is useful for GitOps tools like ArgoCD that need a remote to point at during bootstrap.

Configuration and Authentication: Keys, Anon Access, and Access Tokens

Authentication is based on SSH public keys. When you add a collaborator, you give them access via their public key. The server supports public and private repositories, and you can allow or disallow anonymous access. There is also support for user access tokens, which can be used for HTTP cloning. The `config.yaml` file contains settings like `anon-access` and `allow-keyless`, which control whether anonymous users can read or clone repositories. The README warns that these settings govern reachability, meaning even if a repo is created with `SOFT_SERVE_DEFAULT_REPO`, its accessibility depends on these flags. This is a critical distinction: creating a repo on boot does not automatically make it public. You must explicitly configure access. The database can be SQLite or Postgres, but the README is truncated at that point, so you would need to check the full documentation for the exact configuration keys.

Limitations: Where Soft Serve Falls Short

Soft Serve is not a full-featured Git hosting platform. It lacks a web interface, so there is no pull request workflow, issue tracker, or code review tools. If your team depends on those, this is the wrong tool. The access control model is coarse: you can have public or private repos, but there is no per-branch permissions or granular user roles beyond admin and collaborator. The README mentions SSH authentication and access tokens, but it does not describe fine-grained permissions. Also, the server is designed for small-scale use. The `SOFT_SERVE_GIT_MAX_CONNECTIONS` setting suggests you can limit simultaneous connections to the git daemon, but there is no mention of clustering or load balancing. For a large organization with many users, the SSH TUI might be a barrier to adoption. The documentation is clear that this is a command-line tool, so if your users are not comfortable with SSH, they will struggle.

Alternatives: Gitea and the Web-Based Approach

The most direct alternative is Gitea, a self-hosted Git server with a web UI. Gitea offers pull requests, issue tracking, a web editor, and a REST API. It requires a database (SQLite, MySQL, or Postgres) and a web server, though it ships as a single binary. The key difference is the interface: Gitea is browser-based, while Soft Serve is SSH-based. If your team is distributed and non-technical, Gitea is easier to adopt. But Gitea is heavier: it has more moving parts, more configuration options, and a larger attack surface. Soft Serve's advantage is simplicity and speed. You can spin it up in minutes with just an SSH key. The trade-off is feature depth. For a solo developer or a small team that lives in the terminal, Soft Serve is sufficient. For a team that needs code review, Gitea is the safer bet.

Maintenance, Upgrades, and License

Soft Serve is written in Go, which means it compiles to a single static binary. That simplifies deployment and upgrades: you replace the binary and restart the service. The project is under the MIT license, which gives you freedom to modify and redistribute. The README mentions Systemd service units, so you can run it as a service on Linux. The data directory stores everything, so backups are a matter of copying that directory. There is no mention of migration scripts or version-specific upgrade steps in the provided material, so you should check the release notes for breaking changes. The recent releases (v0.12.0, v0.12.1, v0.12.2) suggest active development, so you should monitor the changelog. The database configuration supports SQLite and Postgres, but the README is truncated, so you need to consult the full documentation to understand the trade-offs. For a small installation, SQLite is likely sufficient; Postgres is for larger setups.

Editorial conclusion

Adopt Soft Serve if you are a small team or a solo developer who prefers terminal workflows and needs a Git server that is trivial to run: a single binary, a data directory, and an SSH key. Avoid it if you need fine-grained access control beyond public/private repos, or if your users expect a web UI for code review and issue tracking. Before adopting, verify that your Git workflow does not depend on features like pull requests or webhooks, and confirm that the SSH TUI is acceptable for your collaborators. Also check the current release notes for any changes to the database configuration, since the README indicates support for both SQLite and Postgres but the details are truncated here.

Official sources

1. Official README
2. Project repository
3. Release notes