How HostStack Runs PostStack on Its Own Infrastructure

HostStack and PostStack are two products from the same team, on the same infrastructure provider, under the same Danish legal entity. HostStack is the European PaaS — managed Postgres, Redis, DNS, services, and crons on dedicated Hetzner servers. PostStack is the European email API — REST, SMTP, MCP, and webmail. Both run inside the EEA, both share a sub-processor list, both bill out of MICCI, and one operations team is on call for both.

This post is a short, honest walk through how that overlap actually works in practice — what the two products share, what they intentionally don't, and what it means for procurement when you put both on your stack.

What HostStack and PostStack share

The overlap sits one layer below the products themselves. Both stacks live on dedicated Hetzner servers in Nuremberg (Germany) and Helsinki (Finland), both get the same OS hardening pass, both deploy through the same Git-driven CI pipeline, and both report alerts to the same on-call channel. Concretely:

• Infrastructure provider. Hetzner Online GmbH for compute, networking, and Storage Box / S3 backups. EU regions only. No US fallback.
• Legal entity. MICCI, Danish CVR 45587452. Both DPAs are signed by the same controller-to-processor counterparty.
• Billing. Stripe (Ireland) with Stripe Tax for EU VAT. Customers of both products show up under the same merchant of record.
• Authoritative DNS. Both products use HostStack's ns1 / ns2 PowerDNS pair for their own zones. When a PostStack customer adds a sending domain that is also on HostStack DNS, PostStack publishes SPF, DKIM, DMARC, and a return-path subdomain straight into the zone — no copy-paste, no TXT-record drift between dashboards.
• Transactional email. HostStack's own signup confirmations, password resets, deploy notifications, billing emails, and support replies are sent through PostStack. The dogfooding runs in this direction — if PostStack's delivery degrades, HostStack's transactional email feels it first.
• Sub-processor list. Hetzner DE/FI, Stripe IE, Let's Encrypt (TLS), plus EU domain registrars on the HostStack side and a couple of operational tools (Telegram for on-call paging). Both DPAs name an overlapping EEA-only set — the legal review you do for one largely covers the other.
• People. One engineer wears both pagers. An incident on either product is triaged by the same person, with full access to both codebases.

What they intentionally don't share

Despite the overlap, the two products are deliberately separate where it matters for users:

• Internal databases. PostStack runs its own Postgres and Redis containers tuned for email-throughput workloads (heavy write traffic, BullMQ queues, full-text search of mailbox content). HostStack runs Patroni HA Postgres and Redis tuned for general-purpose customer workloads (long connections, multi-tenant). Different tuning, different upgrade cadence, different blast radius if a query goes bad.
• Authentication. A HostStack login is not a PostStack login. Different sessions, different 2FA enrolments, different API key formats (hs_live_* vs sk_live_*). By design — if one product is compromised, the blast radius does not include the other.
• SLAs. HostStack's 99.95% SLA covers compute and databases. PostStack's SLA covers the email-acceptance API. Different failure modes, different remediation paths.
• Status pages. Each product has its own status feed, so an unrelated incident on one does not false-positive the other's uptime number.
• Codebases. Two repositories, two test suites, two release trains. The two products talk through public APIs only — no shared private database access, no internal RPC, no implicit trust boundary.

How customers usually wire the two together

The most common pattern is the transactional-email side of a SaaS that already deploys to HostStack. The path looks like this:

1. Add the sending domain in PostStack. If the domain is already in HostStack DNS, PostStack offers to publish SPF, DKIM, DMARC, and the return-path subdomain automatically. One click, around 30 seconds to verify.
2. Generate a PostStack API key and drop it into the HostStack service's environment variables. The same secret-rotation flow you use for everything else applies.
3. Call the PostStack API from your HostStack service. If both sit in the same Hetzner region (Nuremberg or Helsinki), the round-trip is on the order of a few milliseconds over the provider's backbone.

For procurement, the deliverable is one PostStack DPA + one HostStack DPA, both signed by MICCI, both naming overlapping EEA sub-processors. The legal review done for one largely satisfies the other — the same physical infrastructure, the same controller-to-processor model, the same incident-notification path.

When to use which

The shortest possible rule of thumb:

• Need to deploy a web app, an API, a worker, a cron job, or a database? That's HostStack.
• Need to send transactional or marketing email from your own domain? That's PostStack.
• Need both? The two accounts are independent — sign up to one and add the other when you need it. They link through your billing entity, not your login.

Ready to try the combination

If you're already on HostStack and your transactional email currently goes through Resend, SendGrid, or Postmark, moving it to PostStack is usually a one-evening job. The API surface is intentionally close to the providers developers already know, and the DNS integration removes the most error-prone part of onboarding. PostStack's migration guides for Resend, SendGrid, and Postmark walk through the API and DNS changes step by step.

If you're new to both products, the cheapest way to evaluate is the free tiers — a HostStack Nano service plus a PostStack free domain, both EU-hosted, both running on the same hardware that paying customers use. Create a HostStack account to start.