BedVibe — Production Infrastructure

Production Infrastructure · Solo-operated

Production Backend Infrastructure

I architected, deployed, and operate the entire backend behind BedVibe's products — a fleet of independent services on a single self-managed Linux server, fronted by nginx, isolated by systemd, gated by a default-deny firewall, on PostgreSQL. Authentication, device licensing, Stripe billing, AI inference, speech synthesis, and security telemetry — provisioned at the OS level and maintained by one engineer.

nginx (reverse proxy + TLS) systemd service units PostgreSQL 16 Rust (actix-web / axum) Python (FastAPI) ufw default-deny Let's Encrypt / Certbot Stripe (signature-verified) AWS (server-side creds) Self-managed Linux
10independent services
1self-managed box
denydefault firewall policy
soloarchitected & operated
This page describes the architecture at the level a reviewer needs to understand it. Internal addresses, ports, and credentials are intentionally omitted — the system is described, not mapped.

The topology

One Linux host runs every service. Traffic enters through a default-deny firewall that exposes only SSH and HTTP/HTTPS; nginx terminates TLS and reverse-proxies each public hostname to its own service; every service is an isolated systemd unit with auto-restart; PostgreSQL is the shared data layer, bound to localhost.

Clients
Desktop companion · Web products · Webhooks
Edge
Default-deny firewall → nginx (TLS termination · reverse proxy)
Only SSH + HTTP/HTTPS reach the host; every other port is closed to the internet.
Auth
Companion Auth
Email + device (MAC) + subscription gate
Rust · actix-web
Auth
Website Auth
Account login / sessions
Rust
Speech
TTS Service
Server-side synthesis; provider creds never leave the host
Rust · axum
AI
LongBook RAG API
Retrieval / claim-grounding eval
Python
AI
Reception AI
Inbound lead / message intake
Python · FastAPI
Web
Blog
Content / vision blog
Rust
Web
Careers Intake
Submissions + uploads + admin
Rust
Security
Honeypot Sensor
Isolated sacrificial trap + collector
Rust
Data
PostgreSQL 16 — localhost-bound
Users, subscriptions, device licenses, token balances.

How a request flows

A typical authenticated request — and the billing path that keeps entitlement in sync.

Request path
Client
Hostname
Per-product subdomain
Edge
nginx · TLS
Reverse proxy to the service
Service
Auth + license
Email + device + subscription
Data
PostgreSQL
Verify / read / write
Response
Result
Audio / JSON / entitlement
Billing path
Stripe
Checkout
Payment completes
Webhook
Signature verify
HMAC-SHA256 before trust
DB
Entitlement
Flip subscription active
Next login
Unlocked
Service reads the new state

Operational & security posture

Deployment

  • Process isolation: each service is its own systemd unit with auto-restart on failure.
  • Single edge: nginx terminates TLS (Let's Encrypt / Certbot) and maps each public hostname to one service.
  • Shared data layer: PostgreSQL 16, bound to localhost — never exposed to the network.
  • OS-level ops: provisioned, patched, and maintained at the operating-system level, not just inside containers.

Defenses

  • Default-deny firewall: only SSH and HTTP/HTTPS are reachable from the internet.
  • Signed webhooks: Stripe events are HMAC-SHA256 signature-verified before any state change.
  • Device licensing: subscriptions are bound to a device identity, checked server-side against PostgreSQL.
  • Provider isolation: third-party (AWS) credentials live server-side; clients only send bounded requests.
  • Active sensing: an isolated honeypot captures and fingerprints scanner traffic away from the real services.

What I'd redesign today

This platform grew over several years of iterative, hands-on work. Reviewing it now with fresh eyes, these are the changes I'd make — the point isn't that the system is perfect, it's that I can audit my own architecture and reason about the trade-offs.

  • Tighten network binding: bind every internal service to localhost only, so nginx is the single front door and the firewall is defense-in-depth rather than the primary control.
  • Centralize secrets: move provider credentials out of inline service configuration into permission-restricted environment files or a secrets manager.
  • Link the auth steps cryptographically: carry a signed, short-lived token from the login step into each downstream service, so every service verifies the session rather than trusting an identifier.
  • Reproducible deploys: replace manual build-and-copy with a CI pipeline and versioned releases, so every running binary maps to a known commit.
  • Per-user rate limiting on inference and synthesis endpoints, to bound cost even for authenticated traffic.