Most of the applications we build for clients run on our own dedicated hardware in German data centers, not on AWS, Azure or Google Cloud. That is not an ideological position. We have shipped on hyperscalers for years in enterprise projects, and we still use AWS when it is the right tool. But for the typical European SMB application, a dedicated EU setup wins on cost predictability, performance per euro and data residency, as long as someone takes the operational responsibility seriously.
This article explains the trade-offs honestly, including the cases where we recommend the cloud instead.
What "our own EU hardware" means in practice
When we say our own hardware, we mean dedicated physical servers in German data centers that we control end to end: operating system, network configuration, container runtime, databases, backups and monitoring. There is no shared tenancy with noisy neighbors and no opaque platform layer between the application and the machine.
A typical client application on this setup looks like this:
- A reverse proxy terminating TLS and routing to containers
- The application services (for example Node.js APIs and a React frontend)
- A managed-by-us PostgreSQL instance with point-in-time recovery
- Object storage for uploads and backups replicated off-site
- Metrics, logs and uptime checks feeding alerting
It is the same stack you would assemble on a hyperscaler, minus the per-unit billing on every layer. The same setup can also serve as the API backend for a mobile app (see our Ionic to React Native migration notes), and it can host a custom MCP server for company data next to the application it exposes. You can read the service overview on our hosting page.
Cost: flat pricing vs usage-based billing
Where hyperscaler bills drift
Hyperscaler pricing is fair in the sense that you pay for what you use. The problem for SMBs is that "what you use" is hard to predict. The usual sources of drift are well known:
- Egress fees. Data transferred out to the internet is billed per gigabyte. Media-heavy apps, file downloads and API integrations add up quietly.
- Managed service multipliers. A managed database, load balancer, NAT gateway and log ingestion each carry their own line item.
- Scaling by default. Autoscaling protects availability, but a bot wave or a misconfigured job also scales your invoice.
- Plan tiers on platforms built on top of hyperscalers. Request caps, bandwidth limits and forced upgrades when you cross a threshold.
None of this is hidden. It just requires constant attention and cost alerts that most small teams do not have time for.
With our hosting, the price is flat and agreed up front. There are no per-request caps, no bandwidth surprises and no forced plan upgrades. If a marketing campaign doubles traffic for a week, the bill does not change.
Performance per euro
Dedicated servers give you whole physical cores, local NVMe storage and plenty of RAM for what is, in our experience, a fraction of the monthly cost of comparable on-demand cloud instances. The assumption behind that comparison is a steady workload running all month, which describes most business applications: e-commerce, internal tools, customer portals, SaaS backends.
For a store like Hydina Gemer, fast page responses matter directly for conversion. Having headroom on dedicated hardware means we can optimize for speed instead of rationing instance sizes.
Data residency, GDPR and the CLOUD Act
Why location and control both matter
Under GDPR, transfers of personal data outside the EU need a legal basis. The 2020 Schrems II ruling by the Court of Justice of the EU invalidated the Privacy Shield framework, and while the EU-US Data Privacy Framework was adopted in 2023, many legal teams still treat its long-term stability as uncertain.
A separate issue is jurisdiction. The US CLOUD Act allows US authorities to request data from US-based providers regardless of where that data is physically stored. Choosing an EU region on a US hyperscaler addresses location, but not necessarily control. Whether that is a real risk for your business is a question for your legal counsel, not for a hosting vendor.
What EU self-hosting does and does not solve
Running on EU hardware under EU control removes a class of transfer questions: the data never leaves the EU and there is no non-EU parent company in the processing chain for hosting. That is why we describe our setup as GDPR by default.
It does not make an application compliant on its own. You still need processing agreements, retention policies, access control and sensible logging. This matters even more for AI features, which we cover in self-hosted AI for European SMBs and in our article on AI customer support agents.
The honest cost: operational responsibility
A hyperscaler sells you managed building blocks. When you run your own hardware, the responsibility for patching, monitoring, backups, disaster recovery and failover is yours, or in this case ours. This is the part many "just rent a server" setups get wrong, and it is where most of our effort goes.
What we do to cover it
These are practices we apply, not marketing SLAs:
- Infrastructure as code. Servers are provisioned and configured from version-controlled definitions, so a machine can be rebuilt rather than repaired by hand.
- 24/7 monitoring and alerting. Host metrics, container health, database replication, certificate expiry and external uptime checks.
- Automated off-site backups. Encrypted, scheduled, stored outside the primary data center.
- Restore tests. A backup that has never been restored is a hope, not a backup. We restore regularly into a scratch environment.
- Runbooks. Written procedures for common incidents, so recovery does not depend on memory at 3 a.m.
- Hardened security. Minimal exposed ports, key-only SSH, automatic security updates, firewall rules and least-privilege access.
A simplified example of an alert rule we would use for disk pressure:
groups:
- name: host
rules:
- alert: DiskSpaceLow
expr: (node_filesystem_avail_bytes{fstype!="tmpfs"} / node_filesystem_size_bytes) < 0.15
for: 10m
labels:
severity: warning
annotations:
summary: "Less than 15% disk space left on {{ $labels.instance }}"And the shape of a nightly encrypted off-site backup with retention:
#!/usr/bin/env bash
set -euo pipefail
pg_dump --format=custom "$DATABASE_URL" > /var/backups/app.dump
restic backup /var/backups /srv/app/uploads --tag nightly
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%The honest summary: self-hosting is cheaper in money and more expensive in discipline. If nobody owns the discipline, the cloud is the safer choice.
When we don't use our own hardware
Global users and edge latency
If your users are spread across continents and every millisecond matters, a single EU location cannot compete with a global edge network. A static frontend behind a global CDN with an EU backend often solves this, but real-time global apps may need multi-region infrastructure.
Spiky, massive scale
Dedicated hardware is ideal for steady load. If traffic jumps by orders of magnitude for short windows, such as ticket sales or live events, elastic cloud capacity is worth its premium.
Managed services with no good equivalent
Some projects depend on things that are hard to replicate well: burst GPU capacity for model training, specific managed ML services, or global content delivery. Buying these by the hour is usually smarter than owning idle hardware.
Client mandates and compliance frameworks
Some organizations have standardized on a specific cloud, or work under compliance frameworks and procurement rules that require one. We follow the mandate and build accordingly.
In several of these cases we run a hybrid setup: core application and personal data on EU hardware, with AWS handling a specific workload where it genuinely makes sense.
A decision table
| Factor | Own EU hardware | Hyperscaler |
|---|---|---|
| Workload shape | Steady, predictable | Highly spiky or unknown |
| User geography | Mostly Europe | Global, latency-sensitive |
| Cost model | Flat, agreed up front | Usage-based, needs active cost control |
| Performance per euro | High for steady load | Lower, better for short bursts |
| Data residency and control | EU location and EU control | EU region, provider jurisdiction varies |
| Managed services catalogue | What we operate | Very broad |
| Operational responsibility | Ours, via practices above | Shared with the provider |
| Lock-in risk | Low with containers and IaC | Grows with proprietary services |
| Best fit | SMB apps, e-commerce, SaaS backends, internal tools | Global platforms, GPU bursts, cloud mandates |
If most of your answers land in the left column, dedicated EU hosting is likely the better deal. If two or more land firmly on the right, we will usually recommend cloud or hybrid.
How we decide on a real project
We make the hosting decision during architecture, not after launch. The questions are simple: where are the users, what does the load look like over a month, what personal data is processed, which managed services are truly needed, and who will be on call. Because we build web applications and operate our own SaaS, Namiru.ai, in production on this stack, the recommendation comes from engineers who carry the pager, not from a sales table.
If you are unsure which side of the table you are on, a short consulting session usually settles it.
Want a second opinion on your hosting setup or a new build? Tell us about your project and we will send you a free project roadmap within 24 hours, including a hosting recommendation with the trade-offs spelled out.