Where should a system live?
Self-hosted, private hosting or a managed platform: the honest version of this decision has more than one axis, and none of the options is inherently secure.
Organisations increasingly ask whether a system can run on their own infrastructure rather than inside a vendor’s platform. It is a reasonable question, and it deserves a more careful answer than either “the cloud is fine” or “self-hosting is safer”.
Security is not the axis people think it is
A well-run managed platform is patched, monitored and backed up by a team whose full-time job that is. An internal server that nobody has updated since it was installed is not more secure because it is in your building. Location does not confer safety; operation does.
What changes with hosting model is not a single security level but a set of specific properties: who can technically access the data, where it is stored, how long it is retained, what happens at the end of a contract, and how much of that you can verify yourself.
The axes that actually matter
Control. Can you decide who has access, how backups are handled, and when the system changes?
Capability. Does the organisation have — or want — the ability to operate infrastructure? Being honest here prevents a lot of regret.
Continuity. If the supplier disappears, is the system still operable? This is often the strongest practical argument for standard technology and clear documentation.
Obligation. Some sectors have requirements about where information may be processed. Those are constraints to be established early, with your own advisers — not assumptions to be inherited from a vendor’s marketing.
How we approach it
We build on deliberately ordinary technology — PHP, MySQL or MariaDB, standard web hosting — which means a system can run on a shared host, a private server or your own infrastructure without being rewritten. That keeps the hosting decision reversible, which is usually worth more than getting it perfect the first time.