We could do it ourselves — why we don't
OB7 builds white-label SaaS for EV charging. Our customers are utilities, energy providers, and operators of charging infrastructure. Setting up servers ourselves is something we can do. The know-how is in-house.
But every hour spent on server config or SSL cert debugging is an hour missing from the product. Simple arithmetic.
So we deliberately outsource deployment. Not because we can't do it, but because we want to control where our engineering time goes. Building containers, yes. Running them in production, no.
What hides behind "let's just self-host this"
"Let's just self-host this quickly" almost always ends in a pile of work that has nothing to do with the product.
Issue, renew, monitor SSL certificates. Maintain webhooks and CI/CD, usually by someone who should actually be working on the application. Provider accounts, invoices, compliance overhead. Plan and communicate nightly maintenance windows. Even when everything runs smoothly, that's sprint time not flowing into features.
Building containers is part of our product. Everything between "code is done" and "site is live" should not land on our plate alongside the actual work.
We just wanted to deploy
The requirement for lowcloud was simple: we deliver the finished container image. The rest should work without a YAML marathon and without nightly server maintenance.
Today our website runs entirely through lowcloud. Day to day that means:
Connect the registry, set the webhook, deploy. No extra click path, no parallel CI/CD contraption per release that someone still has to maintain.
What runs on autopilot now
Since the switch we don't worry about server provisioning once the image is there. No manual follow-up with the provider, no ticket chain just to spin machines up.
SSL certificates are issued and renewed without us hand-stitching Let's Encrypt and cron jobs together. Every push to GitHub fires a webhook, the deployment rolls out, and after 50 the new version is live. We no longer maintain a pipeline whose only purpose is keeping infrastructure configs current. Load balancing and routing are there, fully configured, and don't eat sprint refining every week.
After the first deployments our team verdict was short: SSL provisioning works, image pulls work, the webhook works. That kind of "boringly good" is what we want in the day-to-day.
tl;dr: We put the container image in, lowcloud puts the website out.
Why not just our own cloud account?
Many teams do well with bring-your-own-cloud: own account, own relationship with the provider, full control. Can be the right call. For us we deliberately wanted the opposite. No Hetzner account to carry, no cloud invoices to distribute across the team, no infrastructure compliance as a permanent task next to the product.
lowcloud hosts on German and European providers, including Hetzner. For OB7 in a regulated space — e-mobility, contracts, high expectations around data and availability — that was a deciding factor. GDPR-aligned, without us assembling the hosting compliance chain ourselves.
In practice: virtually no infrastructure overhead day to day. No guessing before certificates expire, no on-call for "the box". In the end we gain: „2 hours freed up per sprint", „>5 releases/week without infra escalation".
Delegation is a product decision
This step sits right next to our zero-bug policy. Quality isn't only about fixing bugs quickly. It's also about prioritizing the right work and organizing the rest so it doesn't keep coming back as a problem. Delegating here is prioritization, not avoidance.
OB7 stays focused on EV-charging software. We concentrate on what operators and drivers expect at the charge point, and don't open up a second DevOps job inside the team.
If you want similar relief for your team on deployment: lowcloud.io.