When an institution evaluates a new software vendor, the conversation usually starts with features: what does the system do, how fast can it ship, how well does it integrate. Infrastructure rarely comes up until much later, if at all. For consumer apps and early-stage startups, that ordering makes sense. For banks, government bodies, and other regulated institutions, it gets the priority backwards.
Most modern software runs on managed cloud services by default. It is a reasonable default: spin up a database, a queue, a compute instance, and let a provider handle patching, scaling, and failover. For a large share of software, that trade is worth it. But managed cloud carries three properties that matter less for a consumer app and much more for an institutional system: control, cost predictability, and data location.
Control: why someone else's infrastructure limits an institution's choices
A managed service means someone else's infrastructure sits between a system and its data, governed by someone else's terms of service, incident response timeline, and region availability. For most workloads that is an acceptable trade for convenience. For a payment reconciliation engine, an identity system tied to a bank's directory, or any system that needs a specific security posture, it is a constraint the institution never chose. Explicit control over who can access the infrastructure, and how incidents are handled, should be the institution's own decision, not a byproduct of a third party's contract.
Cost predictability: the wrong pricing model for institutional workloads
Managed services price by usage: compute hours, storage, egress, API calls. That model rewards unpredictable, spiky workloads and penalizes steady, high-throughput ones, exactly the profile of an institutional back-office system running the same batch jobs every day at scale. Costs that looked reasonable in a pilot can grow in ways that are hard to forecast a year out, making long-term budgeting harder than it needs to be.
Data location: a requirement cloud-native architecture alone cannot satisfy
A growing number of regulated industries, banking foremost among them, require systems and the data behind them to sit within a specific jurisdiction, sometimes inside the institution's own server room. A cloud-native architecture built around a managed provider's regions cannot satisfy that without real re-architecture. An architecture designed to be portable from day one can.
Self-managed VPS + Docker as a deliberate choice
We build most of our systems on self-managed VPS infrastructure with Docker as the deployment unit. That is not a cost-saving shortcut, it is a direct response to the three points above.
Self-management means an institution's data sits on infrastructure whose location, access controls, and security posture are explicit and auditable, not abstracted behind a provider's shared responsibility model. Docker as the packaging format means the same containerized application that runs on our own servers during development can be handed to an institution's IT team and deployed inside their own network, on their own hardware, without a rewrite. We have built systems this way for clients whose only acceptable deployment target was their own on-premise server, and the architecture did not need to change to get there, only the target it was pointed at.
Deployment discipline, not manual operations
Self-managed does not mean hands-on-keyboard deployments. Every system we run this way still ships through the same CI/CD discipline a managed-cloud deployment would: a pipeline builds the container, runs its test suite, and deploys automatically on every push to the release branch. The infrastructure choice changes where the container ends up, not whether the deployment process is automated, tested, and repeatable. An institution should never have to choose between owning its infrastructure and having a modern deployment pipeline.
Checklist before deciding an institutional system's infrastructure model
- The system handles data subject to a real jurisdiction or residency requirement, not just a preference.
- The workload is steady and high-throughput, not spiky in a way usage-based pricing actually rewards.
- There is a real chance the system will need to deploy inside a client or institution's own network in the future.
- Access control and infrastructure auditing need to be directly verifiable, not fully delegated to a third party.
- The technical team, internal or vendor, has CI/CD discipline that does not depend on one specific hosting model.
Frequently asked questions
Does self-managed VPS mean XETUP never uses managed cloud at all?
No. Managed cloud remains the right choice for plenty of workloads, especially ones that are genuinely unpredictable in scale. What we avoid is defaulting to it without weighing an institution's actual control, cost, and data-location needs.
Does Docker guarantee a system can move to an institution's server at any time?
Docker makes portability far easier than an application written tightly to a specific managed service, but it still requires network, security, and access planning on the institution's side. What it avoids is rewriting the architecture, not all deployment work.
Is self-managed VPS always cheaper than managed cloud?
Not always, and that is not the main argument. The main argument is predictability: a per-server cost is far easier to forecast into a multi-year budget than usage-based cost that can grow with scale.
What kind of system is still better served by managed cloud?
Genuinely unpredictable workloads, short-term projects, or teams without the capacity to run their own infrastructure are still well served by managed cloud. An institution with real control, long-term cost predictability, and data-location requirements is a different case.
Closing
The right infrastructure model is not universal, and managed cloud remains the correct choice for plenty of systems. But for institutions where control, long-term cost predictability, and data location are part of the actual requirement, not an afterthought, the infrastructure decision deserves as much deliberation as any feature on the roadmap. We design for that case by default.
If you want the cost and vendor lock-in side of this argument in more depth, we cover it in infrastructure ownership in digital transformation. For the banking sector specifically, see also why automated reconciliation is becoming non-negotiable for banks. Our cloud and DevOps services are outlined on the services page, and an early, no-commitment conversation is always open through the contact page.