In March 2021, a data center in Strasbourg burned. The fire destroyed one building completely and damaged another. Millions of websites went offline. Some of them never came back - not because the data was gone beyond recovery in principle, but because there were no backups, no contingency, no plan for a scenario that almost nobody had seriously considered. The company running the facility was one of the largest hosting providers in Europe. None of that mattered when the building was on fire.
I am not telling this story to argue that cloud hosting is dangerous. I'm telling it because it happened, it is documented, and it is the clearest possible illustration of a point that gets lost in the comfortable assumption that someone else's infrastructure is inherently more reliable than your own: availability depends on factors you don't control, and the question of where your software runs is a business decision with real consequences, not a technical detail to leave to whoever set up the account.
It is also not a one-time story. In October 2025, a DNS failure in AWS's US-EAST-1 region took services down for fifteen hours, affecting over four million users and more than a thousand companies. In June 2025, an IAM service failure at Google Cloud cascaded into a broader internet disruption that hit YouTube, Discord, Shopify, and Spotify simultaneously. Azure outages in the same period averaged nearly fifteen hours each when they happened. The major providers collectively logged over a hundred significant incidents in a twelve-month window. This is not a fringe risk. It is a recurring pattern at scale, and the organizations that absorbed it best were the ones that had thought in advance about what happens when the dependency fails.
The Cost Argument Is the Simplest One
A VPS at five euros a month is five euros a month, and next month it will still be five euros, and the month after that the same - predictable enough to budget, explain to a board, and forecast across three years without a spreadsheet model.
Cloud pricing is a different animal. The base instance is cheap. The egress costs are not. The managed database adds up. The load balancer, the CDN, the object storage, the monitoring, the redundancy you're told you need - each line item is small, and together they become a number that arrives at the end of the month and occasionally surprises even the people who approved the architecture.
For the size of application this series of posts has been discussing - a dental practice's appointment system, a homeowners association's maintenance tracker, a workshop's equipment log - the cloud's elasticity is a feature you are paying for and never using. You don't need to scale to ten servers during a traffic spike. You have no traffic spikes. You have a hundred users who log in between nine and five. A single VPS handles that without breaking a sweat, at a price you can predict to the cent.
On-premise hardware is a larger upfront cost and a lower ongoing one. A server that costs a thousand euros and runs for five years works out to less than seventeen euros a month before electricity, and the electricity for a low-power server in an office is noise. Organizations that have made this calculation honestly often find that the cloud was convenient but not economical - and convenience is worth something, but not unlimited.
Control Is Not a Technical Preference
When your software runs on infrastructure you own, you make the decisions - the database configuration, the backup schedule and destination, the update cadence, the network rules, the access logs - and when something goes wrong you look at your own system rather than a support ticket queue where the answer might arrive in three business days.
When your software runs on someone else's infrastructure, those decisions belong to them, within the limits of whatever plan you're on. This is usually fine. It becomes relevant the moment something unusual happens - a security concern that requires immediate access to specific logs, a compliance requirement that demands data be handled a particular way, a failure that needs investigation at a level the provider's tooling doesn't expose.
Control is also about the future. A provider can change pricing, discontinue a service, alter terms of service, or be acquired. Each of these has happened, repeatedly, to services that organizations had built dependencies on. On-premise infrastructure doesn't come with that risk. Your server in your rack is yours until you decide otherwise.
The natural objection here is that running your own server requires an ops engineer. It doesn't - not anymore, and arguably not for a long time. The knowledge required to run a Linux server hosting a small application is widely available, well-documented, and frankly not that much knowledge. A developer who can write a web application can learn to deploy one. The commands involved - installing Bun, cloning a repository, configuring a service - are not exotic. The concepts involved - a process that runs, restarts when it crashes, starts on boot - are not advanced operations.
Linux's systemd handles the hard parts of keeping a process alive. A service definition that says "run this command, as this user, restart if it exits, start when the machine boots" is fourteen lines of configuration. Reepolee ships one, and installs it with a single script call - one command copies the service file into place, another enables it, another starts it. The application is running as a managed service. When the server restarts after a power cut or a kernel update, the application comes back up automatically. When something crashes, it restarts within seconds. No ops engineer required - just a developer who spent an afternoon reading about systemd and is comfortable with a terminal.
The same pattern extends to everything else a running application needs. Database backups are a script and a cron job - dump the database on a schedule, copy it somewhere safe, rotate old copies. File backups are the same. Log rotation, health checks, deploy hooks - all of it is solved at the level of shell scripts and standard Linux tooling that has been stable for decades, is documented exhaustively, and requires no proprietary service to run. Reepolee ships scripts for the common cases. The rest is a search and an afternoon.
GDPR and Data Sovereignty
The General Data Protection Regulation has a clear and practical implication for where data lives: you need to know, and you need to be able to demonstrate compliance.
"It's in the cloud" is not an answer.
"It's on our server in our country, accessed only by our staff, with these access controls and this backup policy" is.
For European organizations this matters legally - but the regulation is no longer a European concern alone. California has the CCPA and its successor the CPRA. Brazil has the LGPD. Canada has PIPEDA, with Quebec's Law 25 adding stricter requirements. The UK maintains its own post-Brexit version of GDPR. India passed the DPDPA in 2023. Almost every major jurisdiction either has a data protection framework in force or is actively drafting one. The trend is global and the direction is consistent: organizations must know where personal data lives, control who accesses it, and demonstrate both on request. Data processed by a cloud provider is subject to the provider's data processing agreements, their subprocessors, their data center locations, and the legal jurisdiction those locations fall under. These are auditable questions with real answers, but they require ongoing work to verify and maintain.
Data on your own server in your own building is as simple as it gets for compliance purposes. You know where it is. You control who accesses it. You can produce an accurate record of both on request. For organizations that handle member data, patient data, student records, or any other category of personal information, this simplicity is not just convenient - it is the cleanest path through a regulatory requirement that only becomes more significant over time.
Tunnels Have Changed the Equation
The practical objection to on-premise hosting used to be a real one: getting traffic from the internet to a server in your building required a static IP, port forwarding, firewall rules, and a level of network administration that put it out of reach for small organizations without a dedicated IT person. That objection is largely gone.
Tunneling tools - lightweight agents that run on your server and maintain an outbound connection to an edge node - can expose a locally running application to the internet in minutes, without touching the router, without a static IP, without opening inbound ports. The connection goes out from your server, which means your firewall configuration stays simple and your server is not directly reachable from the internet. And as a side effect, you get a significant amount of infrastructure handled for you at the edge: SSL termination, HTTP/3, response caching, DDoS protection, bot filtering. The kind of things that used to require a dedicated ops setup now come along for free with the tunnel. For small organizations, this is the difference between "we could never do on-premise" and "we set it up on a Tuesday afternoon."
The same infrastructure works for remote employees. A VPN tunnel between an employee's device and the office server gives them access to the local application over an encrypted connection, as if they were sitting in the building. The latency is higher than local network access, but the data stays on your server, the access is controlled by you, and the employee doesn't need the application to live in a cloud they pay for separately.
A VPS fits into this picture naturally as well: a small virtual server close to your users, running the application, with a tunnel or VPN connecting it back to the organization's network if needed. The cost is a few euros a month. The control is yours. The data lives where you decided it should live.
The Internet Goes Down
Here is the argument that gets the least attention and matters the most for a specific category of organization: the internet is not always available, and cloud-only means internet-only.
A broken fiber link. A misconfigured router at the ISP. A backhoe through a conduit. An undersea cable damaged by a ship anchor. These are not hypotheticals - they are things that happen regularly, in developed countries with modern infrastructure, to organizations that had no reason to expect them. When they happen, every application that lives in the cloud becomes unreachable, regardless of how well it was designed or how reliable the cloud provider's uptime record is. The failure is not on the provider's side. The failure is between the provider and your users.
For a school this means nobody can take attendance, look up a student's records, or access the schedule; for a nonprofit it means staff can't look up a member's information while talking to them on the phone; for a warehouse inventory checks stop; for a medical clinic records are unavailable during a patient visit.
An application running on a server in the building continues to work for everyone on the local network regardless of what is happening to the WAN. And for organizations that need external access to stay available even during an ISP outage, a capable router with a 5G backup link is an affordable addition that automatically fails over when the primary connection drops. What used to require enterprise networking budget is now a consumer-grade router feature. The combination - local server, backup WAN - means your application is available to internal users unconditionally and to external users with a level of redundancy that rivals most cloud setups at a fraction of the cost.
An application running on a server in the building continues to work, which means staff can still access it, support can still respond to clients, the phone call with a member can still be resolved, the warehouse can still function, and the clinic can still look up the record, because the internet being down is an inconvenience rather than a work stoppage.
Local Network Performance
A cloud database query travels from your user's browser to your server, from your server to a database in some data center, and back. Each hop takes time. A well-optimized cloud setup might achieve five to twenty milliseconds for a simple query. That is fast by most standards, and for most applications it is more than sufficient.
A database on the same server as the application, on a local 1GB network, answers in microseconds. Not milliseconds. Microseconds. The actual performance limit in any cloud or remote setup is the WAN link - the bandwidth and latency of the internet connection between the user and the server. That link is shared: the same connection carries the video call in the meeting room, the social media tab someone has open, the software update downloading in the background, the colleague on a real-time collaboration tool. All of it competes for the same pipe, and when the pipe is busy your cloud application feels it. On a local network none of that matters. The application traffic stays on the LAN, uncontested, regardless of what everyone else in the building is doing with the internet connection.
The constraint is the CPU and the disk, not the wire.
For an application used by staff in an office or a school, where every user is on the local network, the performance difference between a well-resourced on-premise setup and a cloud deployment is not theoretical - it is something users feel every day in the responsiveness of the interface.
This matters more than it is usually given credit for, because performance is not just a technical metric. An application that responds instantly feels trustworthy and well-built. An application that hesitates - even by amounts a benchmark wouldn't flag as significant - creates friction that accumulates over hundreds of daily interactions into a perception of the software that affects whether people actually use it.
Affiliates, Branches, and the Phone Call
One more scenario worth naming, because it comes up in the kinds of organizations this post is written for: the affiliate or branch that needs access, and the support call that happens when things are complicated.
An organization with multiple locations - a trade union with regional branches, a clinic with multiple sites, a company with branch offices - can connect those locations over a VPN to a central on-premise server and give everyone fast, reliable access to the same system without paying per-seat cloud fees or managing complex cloud networking. The infrastructure is a VPN tunnel and a server. It runs.
And when a member calls with a question, when a client needs help, when something needs to be resolved in real time over the phone - the person on the other end of that call can look it up. Not wait for the internet to recover. Not apologize that the system is currently unavailable. Look it up, because the system is in the building and the building is still there.
The Right Question
The question is not "cloud or on-premise" as an absolute. There are workloads that genuinely belong in the cloud - global products, systems that need to scale unpredictably, anything that requires geographic distribution. That is not what this post is about.
The question is whether the default assumption - that cloud hosting is always the right answer, that on-premise is outdated, that a VPS is a compromise - is being applied without examination to contexts where it doesn't fit. For a nonprofit, a school, a municipality, a small business, a clinic, a cooperative - organizations with bounded audiences, predictable workloads, real privacy requirements, and staff who need the system to work regardless of what is happening to the internet - the honest evaluation often lands somewhere different.
When the optics break in France, when the data center catches fire, when the fiber goes down at the worst possible moment - the organizations that knew where their software ran, controlled who touched it, and kept it close to the people who used it are the ones still working.
Reepolee is designed to run exactly this way: a single server, a single process, no cloud dependencies, git pull and restart. The whole point is that it should fit in your building as naturally as it fits on a VPS.
One distinction worth making: this post is about applications - the membership system, the intranet, the tool staff use daily. A public-facing website that exists to attract visitors is a different workload. It gets traffic from strangers, benefits from a CDN, and has no reason to live on-premise. Reepolee has a prerendering module for exactly this - the public site compiles to static files and deploys to whatever edge or static hosting makes sense, while the application that runs the organization stays on your server, behind your controls, close to the people who depend on it.