Why bare metal for backends?
Because p99 latency is where virtualization hurts. On shared cloud instances, CPU steal and noisy neighbors turn your tail latencies into a lottery. On your own hardware, the same query takes the same time at 3 PM and 3 AM: performance becomes an engineering property, not a weather report.
What makes a good backend box?
RAM that fits your working set (the fastest query is served from memory), NVMe for the hot path, enough cores for your concurrency, and a private network between tiers. Our lineup configures up to 256 GB RAM and mixed NVMe/SSD at checkout, and custom builds scale RAM to double or quadruple that.
Four Reasons Backends Thrive on Dedicated Hardware
No Noisy Neighbors, No Steal Time
Every core, cache line, and I/O queue is yours. Benchmarks run on Tuesday still hold on Friday, which is the consistency that makes capacity planning and SLO math actually work.
Flat, Predictable Economics
One monthly price includes the hardware and 100 TB of traffic on a dedicated 1 Gbps port, with incoming free. No per-vCPU billing, no per-gigabyte egress line items, no invoice archaeology at month end.
A Real Private Network Between Tiers
Split app and database onto separate machines and link them over a private 1 or 10 Gbps LAN. East-west traffic stays off your public port and off the public internet entirely.
Run Anything, Including Hypervisors
Full root on bare metal runs Docker, k3s/Kubernetes, Proxmox, or plain systemd services, with no ports blocked on our side. Consolidate a rack of small cloud instances onto one machine you fully control.
Dedicated Servers We Recommend for Backends
Sized for the two things backends care about: memory for the working set and consistent per-core speed. Every chassis configures NVMe alongside SSD at checkout.
Dual Intel E-2146G
6 Cores, 12 Threads, 3.50 GHz- 13,275 PassMark CPU score
- 32 GB memory (Max 128 GB)
- 2 x 1 TB SSD default storage
- Highest clock speeds in our lineup
Six cores at 3.5 GHz with NVMe options for snappy APIs, queues, and services where per-request latency is the metric that matters.
Configure & order Full specs & detailsDual Intel E5-2650
16 Cores, 32 Threads, 2.00 GHz- 12,870 PassMark CPU score
- 64 GB memory (Max 192 GB)
- 2 x 240 GB SSD default storage
- Balanced cores, memory & storage
16 cores and 64 GB RAM run your app tier, workers, and a production database side by side without stepping on each other.
Configure & order Full specs & detailsDual Intel E5-2678v3
24 Cores, 48 Threads, 2.50 GHz- 24,262 PassMark CPU score
- 128 GB memory (Max 256 GB)
- 2 x 1 TB SSD default storage
- Up to 256 GB RAM for big datasets
24 cores and 128 GB RAM standard (256 GB max) keep large working sets entirely in memory. PostgreSQL, MySQL, and Redis love it.
Configure & order Full specs & detailsPlanning a multi-tier setup? Talk to an engineer · or see the full lineup with live pricing.
Keep the Backend Healthy After Launch
Resource & Disk Monitoring
The Comprehensive Monitoring add-on watches CPU, RAM, swap, load, partitions, SMART health, and RAID state around the clock. Problems become tickets before they become outages.
Backups on Your Terms
Send database dumps and snapshots to a second Maple server or any external destination. Incoming traffic is free, so nightly pushes cost nothing in bandwidth.
Hardware Is Our Problem
When a component fails, our data center team replaces it, and free KVM/IPMI keeps console access in your hands throughout, even when the OS won't come up.
App & Database Hosting FAQ
Yes. It's bare metal with full root, so Docker, k3s, full Kubernetes, or Nomad all run natively with no nested-virtualization penalty. Single-node clusters on one well-sized machine are a popular, refreshingly simple production pattern.
The rule of thumb: enough to hold your working set (the data your queries actually touch) plus headroom for connections and caches. 64 GB covers most production databases comfortably. Our lineup configures up to 256 GB at checkout, and custom builds can double or quadruple that when your working set is the whole dataset.
Yes. NVMe drives are a configuration option at checkout and mix freely with SSDs: NVMe for the database's hot path, SSD for logs, backups, and bulk data.
Start together. A 16-core / 64 GB machine runs both tiers happily for most products. Split when contention appears (backups slowing requests, cache pressure): two Maple servers on a private 1 or 10 Gbps LAN keep database traffic off the public network entirely.
You own the backup strategy: pg_dump, xtrabackup, borg, restic, whatever fits your stack. For destinations, a second Maple server makes an economical target (incoming traffic is free on metered plans, so nightly pushes cost nothing), or push to any external service you already trust.
Yes. Containers or a hypervisor like Proxmox slice one machine into isolated environments, and extra IPv4 addresses (or a /64 IPv6 subnet) give each environment its own endpoint. Many teams run prod + staging + CI runners on a single 32-thread server.
Ready for backends that behave the same every day?
Configure your dedicated server online, or talk it through with one of our engineers first.