Who we are, where the hardware runs, and how to reach us.
A European cloud, built database-first.
ServersCamp is a European cloud that started with one hard problem: where to run serious databases. Most of the engineering went into exactly that, storage latency, commits that survive a power cut, fast cores, backups stored outside the building. The rest of the platform simply benefits. An ordinary web VM here runs on the same storage and the same network a production database gets.
We run every feature in our own production before customers see it, so if something has an ugly failure mode, chances are we met it first, at three in the morning. Prices are flat and public. Included traffic is really included. And any performance number on this site can be reproduced on your own VM with the commands from the docs.
The people who wrote the platform are the ones running it.
Everything from the control panel down to the node agents is our own code. There is no vendor to wait for, so most fixes go out the same day they are found.
A ticket goes straight to the engineers who built the thing you are asking about. You explain the problem once and get an answer from someone who can fix it, usually the same day.
Owned hardware in a Bucharest cage, hyperconverged from the ground up.
Our main site is a private cage at a Bucharest, Romania colocation facility. A second Romanian site and a site in Germany are being prepared as separate availability zones. We own all the hardware, announce traffic from our own autonomous system, and make routing decisions ourselves rather than depending on an upstream reseller.
The fleet runs on enterprise servers for compute and storage, switched on NVIDIA Spectrum with Mellanox ConnectX SmartNICs in every node. Every host link is LACP-bonded for line redundancy. NVMe storage replicates east-west over an RDMA fabric, where the NIC moves data straight between node memory without going through the kernel network stack, so replication never competes with public traffic.
The platform is hyperconverged: compute and storage live on the same nodes, replicated in software, with no separate SAN to fail or saturate. In practice this is why a VM survives its node dying, why a disk can grow while the application keeps writing to it, and why adding capacity means adding a node rather than upgrading three separate systems.
Registration details and registered address.
Talk to us directly: email, phone, WhatsApp, or social.
