DEV Community

Dhiraj Chatpar
Dhiraj Chatpar

Posted on

Why We Self-Host Our Clients' Infrastructure on LXD Containers

#devops #infrastructure #lxd #privacy

Why We Self-Host Our Clients' Infrastructure on LXD Containers

Every cloud provider promises simplicity. And for many use cases, they deliver it. But for a specific segment of clients — healthcare, legal, financial services — the public cloud's shared tenancy model creates compliance problems that money can't easily solve.

Here's why we increasingly recommend (and implement) self-hosted infrastructure on LXD containers.

The Compliance Problem

When a healthcare client tells you their data must comply with PHIPA (BC's Personal Health Information Privacy Act) or PIPEDA, "we host on AWS" isn't a sufficient answer. AWS's shared responsibility model means their infrastructure, your data. The security controls are good, but the audit trail and data residency requirements can be tricky.

Similar issues exist in legal (BC's Law Society rules), accounting (CPABC standards), and financial services.

Why LXD Instead of Full VMs or Kubernetes

LXD gives us containers that feel like VMs but weigh like containers:

  • Full Linux kernel isolation (not containerized namespaces like Docker)
  • Native networking, storage, and hardware access
  • Snapshot, migration, and backup built in
  • Single commands for complex operations: lxc launch, lxc snapshot, lxc move

Compared to Kubernetes: dramatically simpler to operate. Compared to bare VMs: faster to provision, easier to migrate.

The Architecture 

Host (bare metal or dedicated server)
├── LXD bridge (custom networking)
│   ├── Container: PostgreSQL (persistent storage)
│   ├── Container: Nginx reverse proxy
│   ├── Container: Application (FastAPI/Node)
│   ├── Container: Redis (caching/queue)
│   └── Container: Monitoring (Prometheus + Grafana)
Enter fullscreen mode Exit fullscreen mode

Backups go to R2 (S3-compatible, no egress fees). The host is in a Vancouver BC data centre. Client owns the hardware contract. We manage the software layer.

What This Means for Clients

  • Data residency: The database is literally in BC. Not "backed up to BC." In BC.
  • Compliance: The client's own data centre, their own hardware contract, their own audit scope.
  • Cost: Significant savings vs. equivalent RDS/Azure SQL for high-compute, long-running workloads.
  • Portability: Container images can be migrated to new hardware in under an hour.

When NOT to Use This

Self-hosted LXD is not the right answer for:

  • High-availability requirements that need multi-region failover
  • Workloads with highly variable traffic (autoscaling is harder)
  • Teams without someone who can manage Linux systems

For everyone else: it's worth considering.

Reach out at info@netwit.ca if you want to discuss whether self-hosted makes sense for your workload.

Top comments (0)