Meet Compass: The Lightweight Hosting Control Plane We Built

A few months ago, we moved large parts of our websites, applications, and internal infrastructure onto a new dedicated server.

Not a managed black box. Not a preconfigured hosting bundle. A clean Debian system, built up deliberately from the ground.

The full stack was designed and provisioned in-house, with AI assistance where it accelerated the work:

• Caddy as the web server and TLS front door
• PHP-FPM for application execution
• MariaDB for relational data
• Valkey for caching and queues
• Postfix, Dovecot, and Rspamd for mail
• our own company applications
• monitoring, backups, and operational tooling around it.

Today, it runs exactly as intended: fast, smooth, stable, and under our full control.

Provisioning the base server itself is not the difficult part. With Ansible and a well-designed set of playbooks, the underlying machine can be configured repeatably and reliably.

The more interesting question came afterwards: How do you provision classic web hosting resources on top of a modern custom stack?

• A webspace.
• A database.
• Mailboxes.
• Aliases.
• Web statistics.
• Domain-specific configuration.
• Certificates.
• Website repositories and deployments.
• Service reloads.
• Access rules.

Everything one would traditionally expect from a hosting provider — but without giving up architectural control.

That question led to Compass.

Why not just use Plesk or cPanel?

That is the obvious question.

And to be clear: tools like Plesk or cPanel exist for good reasons. They solve a broad category of problems, they are mature, and for many environments they are perfectly acceptable.

But they also impose assumptions.

They bring their own way of structuring the server.

They expect certain service combinations.

They add weight, abstraction layers, and operational habits that may not match a modern, intentionally designed infrastructure.

We wanted something different:

• full control over the stack
• compatibility with our exact architecture
• support for a modern Debian-based setup
• clean provisioning rather than configuration drift
• fast day-to-day management
• no excess surface area
• and a workflow that feels natural for both us and our hosting clients.

So instead of adapting our infrastructure to a legacy hosting panel, we built a management layer around our infrastructure.

The actual problem: webspace provisioning is more complex than it looks

Creating a “webspace” sounds simple until you describe what it really means.

A new domain may require:

• a web server definition
• document roots and directory structure
• PHP-FPM pool settings
• runtime limits
• log handling
• TLS behavior
• database credentials
• mailbox domains
• mail routing
• access permissions
• statistics and analytics integration
• and a reliable way to apply all of that without hand-editing production configuration

Mail is a good example.

Running a mail server for multiple domains and virtual mailboxes is entirely feasible — but not trivial. A new domain or mailbox does not live in one place. It affects multiple services and configuration contexts. Certificates, routing, mailbox definitions, spam filtering, and service reloads all have to line up correctly.

You can manage that manually.

But manual infrastructure management does not scale elegantly. It is repetitive, error-prone, and exactly the kind of work that should become a system once the pattern is understood.

That is the point where our own internal logic tends to kick in: If something is repeated, structurally clear, and worth doing well, we turn it into a tool.

Compass: a simple control layer over a deliberately engineered stack

Compass is our in-house web application for managing these hosting resources.

It allows us — and our clients where appropriate — to create and manage things like:

• webspaces
• domains
• mail domains
• mailboxes
• aliases
• databases
• related access data
• website deployments / webhooks
• web statistics
• and other operational settings

The app itself remains deliberately lean. It is not meant to become an all-purpose hosting empire. It is meant to provide a clean, purpose-built interface to the infrastructure we actually run.

Behind it sits a provisioning mechanism that takes the desired state from Compass, generates the necessary configuration files, and applies them securely to the server.

That separation matters.

Compass is the management interface.

The provisioning tool is the system-facing executor.

The server remains consistent and reproducible.

No random hand edits.

No mystery state.

No “who changed this file last year?” archaeology.

Faster than traditional hosting panels — because it only does what we need

In daily use, Compass has turned out to be remarkably pleasant.

Adding a mailbox is quick.

Creating an alias is quick.

Provisioning a database is quick.

Adding a webspace or adjusting its settings is quick.

And because the application is shaped around our operational model, the interaction often feels simpler than using broader commercial hosting panels.

That is not because those panels are poorly made. It is because Compass has a much narrower and more intentional scope.

It does not need to support every possible hosting style from the last twenty years. It needs to support our stack exceptionally well.

That focus makes it:

• lightweight
• fast
• predictable
• easy to navigate
• and pleasant to use under real working conditions

The website you are reading right now is hosted on this infrastructure. So are most of our other websites and a growing set of client environments.

It has moved from experiment to trusted operational backbone.

Real-time web analytics from raw Caddy logs

One of the particularly satisfying parts of this infrastructure is the analytics layer.

Our Caddy JSON logs are processed in real time through Vector, then ingested into ClickHouse for analysis.

That gives us a lightweight, highly performant basis for traffic insights directly from our own infrastructure:

• requests
• response behavior
• referrers
• devices and user agents
• error trends
• traffic patterns
• and more

The result is not just “webstats” in the old shared-hosting sense. It is a far more flexible analytics foundation that can be expanded as needed and aligned with how we want to understand our systems.

Compass integrates this into the overall experience, so website operation and website visibility live much closer together.

For a hosting platform, that is a powerful addition. For us internally, it is simply very useful.

Built for clients too

Compass is not only an internal admin convenience.

It also supports client self-management where that makes sense.

Clients can manage selected parts of their hosting environment without sending a request for every small change. At the same time, the system remains constrained and clean. They are not dropped into a sprawling server panel with dozens of irrelevant options. They interact with exactly the parts that matter to them.

That balance is important:

• enough autonomy to remove friction;
• enough structure to preserve reliability;
• enough simplicity that the tool does not require its own training program.

This is how we prefer to build systems in general.

Not maximal feature count. Maximum usefulness.

A very Neoground kind of project

Compass is a good example of how we work.

We did not start with the idea of building “a hosting platform.” We started with a real operational need:

We wanted to run modern, high-control infrastructure without making routine hosting management painful.

Then we designed the system around that need.

That involved:

• infrastructure architecture
• automation
• mail system design
• secure provisioning
• web application development
• analytics pipelines
• user experience
• and operational pragmatism

It is one of those projects where many of our strengths converge: seeing the whole system, refusing unnecessary compromises, and turning complexity into something clean enough to use every day.

That is also what we help clients with far beyond hosting.

Sometimes the answer is strategic advisory.

Sometimes it is process redesign.

Sometimes it is AI and automation.

Sometimes it is a custom application that removes an entire layer of recurring friction.

Compass happens to be a particularly tangible example.

Will we open source it?

Possibly.

A large part of Compass and its surrounding tooling could be genuinely useful to other technically capable teams that want:

• a modern self-managed hosting stack
• a lighter alternative to traditional control panels
• or simply inspiration for building their own management layer around custom infrastructure

We are currently considering open-sourcing substantial parts of it, depending on interest and feedback.

This post is, in a way, the first public showcase of what we have built.

If the concept resonates — especially with developers, agencies, hosting-adjacent teams, or infrastructure-minded businesses — that would be valuable to know.

The quiet power of building your own leverage

Not every company should build its own hosting control plane. Of course not.

But every company should occasionally ask: Where are we still tolerating recurring friction because no standard tool quite fits — and what would happen if we solved that properly?

Compass exists because we asked that question seriously.

The result is a system that makes our infrastructure easier to operate, our hosting services more elegant, and our daily work more streamlined.

It is not flashy in the shallow sense.

It is better than that:

it quietly removes friction every single day.