Royal Army College

Lesson Overview

Every system the earlier lessons described, the servers and services, the identity provider, the registers, the storage, runs somewhere: on real computers, in a real place, owned or rented by someone. That "somewhere" is the question of hosting, and for a small, sovereign, digitally-organised Principality it is not a mere technical detail but a question with real consequences for control, cost, sovereignty, and resilience. A service can be self-hosted, run on hardware the Principality controls, or cloud-hosted, run on infrastructure rented from a provider, or, as is most common in practice, some mixture of the two, a hybrid. This lesson is about those choices: what cloud hosting and self-hosting are, the trade-offs between them, why sovereignty makes the choice weighty for this Principality in particular, and how a small force decides where its systems should live.

The governing idea is that where a system is hosted is a decision about control versus convenience, and for a sovereign state, control is not a luxury. Cloud hosting offers great convenience, the provider supplies and runs the infrastructure, handles much of the hardware and its reliability, and lets a small team field capability it could not build alone, but at the cost of depending on that provider, who controls the infrastructure and, in some sense, holds the data. Self-hosting offers control and sovereignty, the Principality owns and governs its own systems and data, with no provider between it and its infrastructure, but at the cost of having to provide and run everything itself, which demands more effort and expertise. Neither is simply better; the right choice depends on what a given system needs, and a sovereign Principality weighs the sovereignty and control that self-hosting gives especially heavily, particularly for the systems that are its very substance. The disciplined approach is to choose hosting deliberately, system by system, by what each needs, rather than defaulting unthinkingly to either.

This is the knowledge layer; the practice of actually hosting and running systems is done under those who administer the estate, with elevated access following appointment as the course's final lesson sets out. It draws on the reality of running a small, self-hosted, sovereign digital estate, and is wholly defensive: about understanding and supporting the Principality's systems, never about attacking anyone's. Read this to understand hosting; the practice comes from working on real systems under guidance.

By the end you will be able to explain what hosting is and why it matters, describe cloud hosting and self-hosting and their trade-offs, explain why sovereignty makes the hosting choice especially weighty for a digital Principality, understand the hybrid approach, and reason about where a small force's systems should be hosted.

Key Terms

Hosting: the provision of the computers and infrastructure on which a system or service actually runs, whether owned or rented.
Self-hosting: running systems on hardware and infrastructure the organisation controls, giving control and sovereignty at the cost of running everything itself.
Cloud hosting: running systems on infrastructure rented from a provider, who supplies and operates the hardware, giving convenience at the cost of dependence.
Cloud provider: a company that rents out computing infrastructure and services over the internet, running the hardware so customers do not have to.
Sovereignty (digital): an organisation's control over its own systems and data, including where they live and who can access them, which self-hosting protects and cloud dependence dilutes.
Managed service: a service the provider runs and maintains for you, reducing your effort but increasing your dependence on them.
Dependence (vendor lock-in): reliance on a particular provider, such that leaving or losing them is difficult, a risk of heavy cloud use.
Hybrid hosting: a mixture of self-hosted and cloud-hosted systems, using each where it best fits.
Total cost of ownership: the full cost of a hosting choice over time, including not just the rent or hardware but the effort, expertise, and sustainment it requires.
Data residency: where data physically lives and under whose jurisdiction and control it falls, a key concern of digital sovereignty.

What hosting is and why it matters

Behind every running service is the plain fact that software needs a computer to run on, and that computer must be provided, powered, connected, and maintained by someone, somewhere. Hosting is the provision of that underlying infrastructure, the computers, storage, and network on which the systems actually run, and the question of who provides it and where is the question this lesson answers. It is easy to use a service without thinking about where it lives, but for those who support and administer a Principality's systems, where the systems are hosted shapes what control there is over them, what they cost, how resilient they are, and, for a sovereign state, who ultimately holds the keys to its substance.

Hosting matters in four dimensions worth naming, because the choice between hosting options is a trade-off among them. Control is how much the organisation governs its own infrastructure, from the hardware up. Cost is what hosting takes, over time, in money, effort, and expertise. Sovereignty is the organisation's command over where its data and systems live and who can touch them, which for a state is a matter of independence. And resilience is how reliably the systems keep running, and on whose competence that depends. Every hosting choice strikes a particular balance among control, cost, sovereignty, and resilience, and there is no choice that maximises all four, which is why hosting is a genuine decision rather than an obvious default.

For the Royal Kaharagian Army and the Principality, the choice carries extra weight because the Principality is, in large part, its digital systems. A conventional organisation's hosting choice affects its IT; a digital Principality's hosting choice affects its very substance, where its statehood lives, who controls its records and identity, whether its independence extends to its infrastructure. This makes hosting, for this Principality, not a back-office technicality but a question touching sovereignty itself, which is why the sovereignty dimension below weighs so heavily in its choices. Understanding hosting is therefore part of understanding what it means for this state to be digital and sovereign at once.

Cloud hosting and self-hosting

The two basic ways to host are to rent infrastructure from a provider (cloud hosting) or to run it yourself (self-hosting), and understanding each, with its strengths and costs, is the foundation of the choice.

Cloud hosting means running your systems on infrastructure rented from a cloud provider, a company that owns and operates large amounts of computing capacity and rents it out over the internet. Its strengths are real and are why so much of the world uses it. The provider supplies and runs the hardware, so you do not have to buy, house, power, or maintain physical servers; it offers scale and convenience, capacity available on demand and managed services the provider operates for you; and it lets a small team field capability it could never build and run alone, which is genuinely valuable to a small force. The cost is dependence: you rely on the provider for your systems' existence and operation, the provider controls the underlying infrastructure, your data lives on their hardware under their and their jurisdiction's reach, and leaving or losing a provider can be hard (the lock-in risk). With the cloud, you gain convenience and capability and give up a measure of control and sovereignty.

Self-hosting means running your systems on hardware and infrastructure the organisation controls, its own servers, whether physical machines or rented raw capacity it administers itself. Its strengths are the mirror of the cloud's costs: control and sovereignty, you own and govern your own systems and data, with no provider between you and your infrastructure and your data residing where you choose under your own command; independence, your systems do not depend on a particular provider's continued goodwill or existence; and often lower running cost for a stable, known workload. The cost is effort and expertise: you must provide, run, secure, maintain, and sustain everything yourself, which demands the capable, disciplined members this whole course is building, and you carry the resilience on your own competence rather than the provider's. With self-hosting, you gain control and sovereignty and take on the work of running it all.

   CLOUD vs SELF-HOSTING  (a trade of control for convenience)

                    CLOUD HOSTING              SELF-HOSTING
   CONTROL          the provider's infra       YOURS, from the hardware up
   CONVENIENCE      high: they run the          lower: you run everything
                    hardware + managed services
   SOVEREIGNTY      diluted: your data on       PROTECTED: your data where
                    their infra/jurisdiction    YOU choose, under your command
   EFFORT/EXPERTISE less (they do much of it)   MORE (you do it all)
   DEPENDENCE       on the provider (lock-in)   on your own competence
   COST             pay-as-you-go; can grow     hardware up front; often
                                                cheaper for stable workloads

   Neither is simply better. Choose by what each SYSTEM needs.

Sovereignty and the weight of the choice

For most organisations the cloud-versus-self-hosting choice is mainly about convenience and cost; for a sovereign, digitally-organised Principality, a third consideration, sovereignty, presses harder and shifts the balance, especially for the systems that are the state's substance. Digital sovereignty is the Principality's control over its own systems and data: over where its data lives (data residency), who can access or compel it, and whether its statehood's infrastructure is under its own command or another's. Self-hosting protects this sovereignty, because the Principality's records, identity, and systems sit on infrastructure it controls; heavy cloud dependence dilutes it, because the state's substance then lives on a provider's infrastructure, under that provider's control and its jurisdiction's laws, reachable by parties the Principality does not govern.

This matters acutely for a state whose very existence is digital. A conventional country's sovereignty rests on its territory and institutions, and its choice of cloud provider for some IT does not touch its statehood; the Principality of Kaharagia, non-territorial and digitally organised, has much of its statehood in its systems, so the question of who controls those systems is, in part, the question of how far its sovereignty actually extends. A Principality that hosted its core records, its identity, its registers, entirely on a foreign provider's infrastructure would have placed the substance of its statehood under another's ultimate control, which is a real diminution of sovereignty however convenient; one that self-hosts its core systems keeps the substance of its statehood in its own hands. This is why the Principality, in reality, runs a substantially self-hosted estate, and why those who support it should understand that the self-hosting is not merely a cost preference but a sovereignty choice.

This does not mean the cloud is forbidden or sovereignty is the only consideration; it means sovereignty is weighed heavily, especially for the core systems that constitute the state, while convenience and capability may rightly win for peripheral systems where sovereignty is less at stake. The disciplined judgement is to ask, of each system, how much its control and data residency matter to the Principality's sovereignty, and to weight self-hosting accordingly, keeping the state's substance under its own command while using the cloud where the sovereignty cost is low and the convenience high. The member supporting these systems understands that, for this Principality, where a system is hosted is partly a question of how sovereign the state chooses to be over its own digital substance.

The hybrid, and choosing for a small force

In practice almost no real estate is purely one or the other; most are hybrid, a deliberate mixture of self-hosted and cloud-hosted systems, using each where it best fits. The hybrid is not a failure to decide but the sensible recognition that different systems have different needs: the core, sovereignty-critical systems, the records, the identity, the state's substance, are self-hosted to keep them under the Principality's control; while peripheral or convenience systems, where sovereignty matters less and the cloud's capability or reliability is valuable, may be cloud-hosted. A well-designed hybrid gives the Principality sovereignty where it matters and convenience where it does not, which is usually a better outcome than either extreme: a purely self-hosted estate may take on more effort and less reliability than a small force can sustain everywhere, while a purely cloud-hosted one surrenders sovereignty the state should keep.

Choosing the hosting for a small force, then, is a matter of judging each system by what it needs and what the force can sustain, against the four dimensions of control, cost, sovereignty, and resilience. The questions are plain: how much does this system's control and data residency matter to the Principality's sovereignty (favouring self-hosting for the core)? What is the total cost of ownership, including the effort and expertise to run it, against what the small force can actually sustain (favouring the cloud where self-hosting would overstretch the team)? How reliable must it be, and whose competence can best provide that reliability? And what does dependence on a given provider risk? The disciplined answer is rarely "all cloud" or "all self-hosted" but a considered hybrid: self-host the sovereign core, use the cloud for what it serves well and the force cannot better provide itself, and decide each system deliberately rather than by default. The member who understands these trade-offs can reason about where the Principality's systems should live, which is the foundation of supporting a small, sovereign, self-hosted-where-it-matters estate.

In Practice: Deciding Where Systems Live

A member of the Royal Kaharagian Army learning to support the Principality's systems studies how its hosting is decided, and finds the answer is not a slogan, neither "the cloud is best" nor "self-host everything", but a considered judgement, system by system, against control, cost, sovereignty, and resilience. A naive approach would default everything to the cloud for convenience, surrendering sovereignty, or insist on self-hosting everything for purity, overstretching the small team; the disciplined approach is the hybrid the Principality actually runs.

The core, sovereignty-critical systems, the registers and records that make Kaharagia a state, the identity service that holds its accounts, the substance of its digital statehood, are self-hosted, on infrastructure the Principality controls, because for these the sovereignty consideration dominates: the member understands that placing the state's substance on a foreign provider's infrastructure would put it under another's ultimate control and under another jurisdiction's reach, a real diminution of the sovereignty that, for a non-territorial digital state, partly is its statehood. So the Principality keeps its core in its own hands, accepting the effort and expertise that self-hosting demands, which is exactly why capable, disciplined members like this one are grown to support it.

For peripheral systems, where sovereignty is less at stake and the cloud's convenience or reliability is genuinely valuable, the judgement tilts the other way, and those may be cloud-hosted, giving the small force capability it could not itself sustain without surrendering anything that matters. The result is a deliberate hybrid: the sovereign core self-hosted, the convenience periphery in the cloud, each system decided by what it needs and what the force can sustain, against the four dimensions. The member comes to see that, for this Principality, hosting is not a back-office detail but a standing expression of how sovereign the state chooses to be over its own digital substance, and that supporting the estate well means understanding why each system lives where it does. That understanding, the considered judgement of where systems should be hosted, is what this lesson builds.

Check Your Understanding

Explain what hosting is and the four dimensions a hosting choice trades among (control, cost, sovereignty, resilience). Why does where systems are hosted carry extra weight for a non-territorial, digitally-organised Principality?
Describe cloud hosting and self-hosting, with the strengths and costs of each (convenience and capability versus dependence; control and sovereignty versus effort and expertise). Why is neither simply better?
Explain why sovereignty presses harder for this Principality and shifts the balance toward self-hosting the core systems, what data residency and dependence mean, and how a hybrid approach and a system-by-system judgement give sovereignty where it matters and convenience where it does not.

Reflection (write a short paragraph): This lesson argues that for a non-territorial digital Principality, much of its statehood lives in its systems, so the question of who controls those systems is partly the question of how far its sovereignty extends, and that this is why it self-hosts its core. Why might it be tempting for a small, stretched force to put even its core systems in the cloud for convenience, and what would it quietly give up by doing so? Then think about the hybrid: why is deciding hosting system by system, self-hosting the sovereign core and using the cloud for the convenient periphery, usually wiser than committing wholesale to either?

Summary

Hosting is the provision of the infrastructure a system runs on, and the choice of where systems live trades among control, cost, sovereignty, and resilience, with no option maximising all four. For a digital Principality whose statehood lives in its systems, hosting touches sovereignty itself, not just IT.
Cloud hosting rents infrastructure from a provider: convenience and capability (the provider runs the hardware and managed services; a small team fields more than it could alone) at the cost of dependence (the provider controls the infrastructure, the data lives under their reach, lock-in is a risk). Self-hosting runs systems on infrastructure the organisation controls: control and sovereignty and independence at the cost of effort and expertise (you run, secure, and sustain everything). Neither is simply better.
Sovereignty presses hardest for this Principality, because much of its statehood is its systems, so hosting its core (records, identity, the state's substance) on a foreign provider would place that substance under another's control and jurisdiction. Self-hosting protects sovereignty and data residency; the Principality therefore self-hosts its sovereign core.
Most real estates are hybrid: self-host the sovereignty-critical core, use the cloud for peripheral or convenience systems where sovereignty matters less and capability or reliability is valuable. Choose system by system, judging each against the four dimensions and total cost of ownership versus what the small force can sustain, rather than defaulting wholesale to either.
This is the knowledge layer; the practice of hosting and running systems is done under those who administer the estate, with elevated access following appointment (Lesson 10). The lesson builds on the systems and network of Lesson 02, underlies the keeping-running of Lesson 04 and the continuity of Lesson 05, leads into the containers of Lesson 07 (how hosted services run), and connects to the reach-back and sovereignty themes of SIG 410. Everything here is defensive.

Hosting: Cloud, Self-Hosting, and the Hybrid