Why Self-Hosted?

The Problem with SaaS SSH Access

SaaS SSH access tools ask you to route your most sensitive connections through a third-party cloud. Think about what that means in practice: every SSH session, every terminal command, every file transfer passes through infrastructure you do not own or control. Your session recordings, your audit logs, your certificate authorities — all of it lives in someone else’s account.

For many organizations, this is an acceptable trade-off. But for teams working under strict compliance requirements — financial services, healthcare, defense, or any organization handling sensitive data — it creates problems that no amount of SOC 2 reports can fully resolve.

Data Sovereignty

Regulations like GDPR, HIPAA, and sector-specific frameworks often require that sensitive data remain within specific geographic or organizational boundaries. When your SSH access platform is SaaS, your session recordings — which may contain database credentials, API keys, configuration secrets, and application data displayed in terminal output — are stored and processed outside your boundary.

Your CA, Your Control

The Certificate Authority that signs your SSH certificates is the root of trust for your entire SSH infrastructure. With a SaaS platform, the vendor operates the CA. You trust their key management, their signing logic, and their operational security with the ability to generate credentials for any server in your fleet.

With Mezite, the CA runs on your infrastructure. The Ed25519 private keys are stored encrypted in your PostgreSQL database. You control the backup strategy, the access policies, and the rotation schedule. No third party can sign certificates for your infrastructure.

No Vendor Lock-in

SaaS vendors can change pricing, get acquired, deprecate features, or shut down. When your SSH access depends on a vendor’s continued operation and goodwill, you have a single point of failure that is outside your control. With a self-hosted binary running inside your network, the only runtime dependency is your own infrastructure.

The Single Binary Advantage

Mezite ships as a single signed binary. There is no JVM, no container orchestrator dependency, no microservices graph to reason about. You deploy one binary and a PostgreSQL database. Upgrades mean replacing the binary and running a migration. Backups mean backing up PostgreSQL.

This matters because operational simplicity is a security property. Every additional component in your SSH access platform is a potential failure point and an additional surface to secure. Fewer moving parts means fewer things that can go wrong, fewer things to patch, and a smaller attack surface.

Go + SQLite/PostgreSQL

We chose Go and a simple database stack deliberately. Go produces statically-linked binaries with no runtime dependencies. For the simplest deployments, Mezite uses SQLite with zero external dependencies. For production and managed deployments, PostgreSQL is the most well-understood relational database in the world, with decades of tooling for backup, replication, monitoring, and high availability.

This stack means your operations team already knows how to run Mezite’s infrastructure. There is no new database to learn, no message queue to operate, no cache layer to tune. If you can run a Go binary, you can run Mezite.

How Mezite Makes Self-Hosting Easy

• Single binary deployment — Download, configure, run. No container orchestration required for the control plane.
• SQLite or PostgreSQL for state — Zero dependencies with SQLite, or use PostgreSQL for production with its decades of backup, replication, and monitoring tooling.
• Automatic migrations — Database schema upgrades happen automatically on startup. No manual migration steps between versions.
• Agent-based architecture — Target nodes run a lightweight agent that connects outward via reverse tunnels. No inbound firewall rules to manage.
• systemd unit files included — Production-ready systemd units with security hardening (ProtectSystem, NoNewPrivileges, capability restrictions) are provided in the repository.

Self-hosted does not have to mean self-managed headaches. With the right architecture decisions, it means you get full control without the operational tax.

Ready to try it? Start with the Quickstart Guide and have a running cluster in under five minutes.

---