What self-hosting a CRM actually means

"Self-hosting" carries a lot of baggage. People hear it and picture a humming box in a closet, a security incident waiting to happen, and a weekend lost to config files. That reputation was earned a decade ago. For a modern CRM that ships as a container, the reality is much closer to running a single application. It's worth understanding before you rule it in or out.

What you're actually running

Nanobox CRM ships as a Docker image with a PostgreSQL database and built-in authentication via better-auth. Concretely, self-hosting means you run two things: the app container and a Postgres database. That's the shape of it. You point a domain at the server, set a handful of environment variables, and the app handles sessions, accounts, and your data on infrastructure you control.

You are responsible for the server, backups, and applying updates. That's the honest trade. In exchange, your customer data never leaves your machine, there's no per-seat meter running, and you have the full source if you ever need to change something.

Who self-hosting is right for

• You already run infrastructure. If a Postgres database and a container are familiar territory, this is a Tuesday, not a project.
• Data residency or privacy matters. Regulated industries, or anyone who simply doesn't want customer records on a third party's servers.
• You want to own and modify. Having the source means a missing field or an odd workflow is an edit, not a support ticket that goes nowhere.

Who should skip it

Be honest with yourself here. If nobody on the team is comfortable with a terminal, if you don't want to think about backups, or if you'd rather spend your attention on customers than on uptime, then self-hosting is a tax you don't need to pay. That's not a failure; it's a sane allocation of effort.

For those teams we run it for you. The hosted plan is the same software on our infrastructure, flat-rate, with updates and backups handled. You get ownership of your workflow without owning a server.

Try before you commit

The best way to decide is to read what operating it involves. The documentation at /docs walks through deployment, environment setup, and day-two operations so you can judge the effort against your team honestly. Self- hosting isn't for everyone. But for the right team it's far less than its reputation suggests, and the payoff is software that's genuinely yours.