Lesson Overview
CIS 201 taught you to use the Principality's systems safely: to choose a strong passphrase, switch on multi-factor authentication, spot a phishing lure, and report trouble at once. Those are the habits of a careful user, and they matter. This course goes one layer below them. Before you can help run a system, or one day administer it, you have to understand what a system actually is, what kinds of system a digital state depends on, and how they fit together into something a small force can keep running. This first lesson draws that map. It does not yet teach you to operate anything; it teaches you to see the shape of the estate you are joining.
The Principality of Kaharagia is non-territorial and digitally organised, which means its working parts are not buildings and offices but online services: an identity service that holds the accounts, the registers and records that make it a state, the services its people use, the storage that keeps its data, the communications that carry its messages, and the network that ties all of it together. This lesson names those system types in plain terms, explains the difference between a service, a server, and a client, and sets out one choice that shapes everything else, whether a sovereign state runs its systems on its own machines or rents them from a cloud provider. Self-hosting buys control and sovereignty, and in return it obliges the Principality to maintain, update, and secure what it runs. Understanding that bargain is the beginning of the systems mindset this course is built to grow.
This is the knowledge layer. Reading about a backup does not take one, and understanding an identity service does not grant you access to it. The practical parts of this speciality, configuring multi-factor authentication on a real account, running and checking a backup, walking through a reporting drill, are practised and signed off in person where supervision allows, on systems you are appointed to touch and under the eye of someone responsible for them. By the end you will be able to explain in plain terms what a service, a server, and a client are; name the kinds of system a non-territorial Principality depends on and say what each is for; explain self-hosting versus the cloud and why a sovereign state often self-hosts; state the duties that self-hosting creates, to maintain, update, and secure; and describe the systems mindset that lets a member understand and help run an estate rather than only use it.
Key Terms
- Service: software that does a job. A website, a records system, a chat or comms server, a file store, and an identity service are all services. When people say "the roster system" or "the register" they usually mean a service.
- Server: a computer whose job is to run services and answer requests. It need not be a special machine in a room; it is defined by its role, running services and serving others, not by its shape.
- Client: the device a person actually uses, a phone, a laptop, a tablet, that connects to a service and asks it to do something. You read this lesson on a client; it was served to you by a server.
- Identity service: the single system that holds accounts and decides who you are, so that one account can sign you in to many services. Also called an identity provider or single sign-on. Identity is studied in depth in CIS 220.
- Register or record system: a service that holds the Principality's authoritative information, such as the register of nationals or the record of decisions. For a digital state these are not back-office files; they are much of where the state lives.
- Storage: where data is kept so it survives and can be found again: databases, file stores, and the data volumes a service writes to. Backups are copies of storage kept safe elsewhere.
- Network: the wiring, wireless, and routing that lets clients reach services. The LAN is the local network; the WAN or internet is the wide one that reaches across the world.
- Self-hosting: running a service on your own server, under your own control, so you decide how it is configured, secured, and changed. The opposite is cloud, renting the service or the server from another provider.
- Cloud: computing and services rented from an outside provider and reached over the internet. Convenient and quickly available, but run on someone else's machines under someone else's terms.
- Sovereignty (in the digital sense): the Principality keeping control of its own systems, data, and decisions rather than depending on, or being beholden to, an outside party. A central reason a small sovereign state self-hosts.
Service, server, client: the three plain words
Almost everything in this course is easier once three words sit firmly in place, because nearly every system you will meet is built from them. They are service, server, and client, and the cleanest way to fix them is with the picture you are inside of right now.
A service is software that does a job. The job might be showing a website, holding a register, carrying a chat message, storing a file, or signing you in. A service is not a machine and not a screen; it is a running program with a task. When a member says "the records system is slow today", they are talking about a service.
A server is a computer whose role is to run services and answer requests for them. The word describes a job, not a kind of hardware. A server may be a powerful machine in a data centre, or a modest box, or a slice of a larger machine; what makes it a server is that it sits there running services and serving others rather than being the thing a person types on directly.
A client is the device a person uses to reach a service: a phone, a laptop, a tablet. The client asks, the server answers. You opened this lesson on a client. It asked a server for the page, the server ran the service that produced it, and the page came back to your screen. That exchange, a client asking and a server's service answering, is the basic shape of nearly everything the Principality runs.
CLIENTS THE NETWORK SERVERS
(devices people use) (LAN, then the internet) (run the services)
+------------+ +----------------+
| laptop |---\ /---->| identity svc |
+------------+ \ / +----------------+
\ request -----> /
+------------+ \ +------------------+ / +----------------+
| phone |-------+->| reverse proxy / |-+-------->| records / reg. |
+------------+ / | routing in front| \ +----------------+
/ +------------------+ \
+------------+ / <----- answer \ +----------------+
| tablet |--/ \---->| comms / storage|
+------------+ +----------------+
A client ASKS. A server's service ANSWERS. The network carries both ways.
Hold those three words and a great deal of jargon stops being mysterious. A "web server" is a server running a service that serves web pages. A "mail client" is the program on your device that talks to a mail service. The whole estate is clients asking and servers answering, again and again, all day.
The systems a digital Principality depends on
A territorial state can point to buildings: a registry office, a post room, a records archive, a telephone exchange. The Principality has the same functions, but it meets them with services running on servers rather than with rooms. It is worth naming the main kinds, because together they are the estate this speciality protects and helps run. None of what follows reveals how any particular Kaharagian system is built; it is the general shape that any small digital state shares.
An identity service for the accounts. A digital state must know who everyone is and let the right person reach the right system. Rather than a separate login on every service, one identity service holds the accounts and signs a person in across many systems at once. This is single sign-on, and it is the spine of the whole estate, which is exactly why it is guarded so carefully and studied on its own in CIS 220.
The registers and records that make it a state. This is the heart. The register of nationals, the record of decisions, the registers a state keeps, these are the authoritative information that, for a non-territorial Principality, is much of where the state actually lives. If a country with land loses a database for a day, its territory and its people are still there. For Kaharagia the records carry a heavier load, and protecting their accuracy and their availability is close to protecting the state itself.
The services its people use. Beyond the registers sit the everyday services through which members and nationals do things: apply, enrol, be recognised, read notices, take part. These are the public face and the working face of the Principality, the places where a person actually meets the state.
Storage that keeps the data. Every register, record, and service writes data somewhere, into databases and file stores. Storage is where information persists between one use and the next. Because so much of the Principality is information, the storage and, just as importantly, the backups of it are precious. Lesson 05 of this course is devoted to them.
Communications that carry the messages. A state has to talk to itself and to its people: notices, messages, the channels members use to coordinate. For a force the secure carriage of communications is its own discipline, taught alongside this course in SIG 220, but it is one of the system types the estate is made of.
The network that ties it all together. None of the above is reachable without the network. Clients reach services across the LAN and the internet, names are turned into addresses, and traffic is routed to the right service and protected in transit. The network is not one of the systems so much as the thing that makes the others usable. Lesson 02 of this course opens it up.
A MAP OF A SMALL DIGITAL STATE'S SYSTEM TYPES
+------------------------------------------------------------------+
| IDENTITY SERVICE |
| one account, signs people in across everything below |
+------------------------------------------------------------------+
| | | |
v v v v
+--------------+ +-------------+ +--------------+ +--------------+
| REGISTERS | | SERVICES | | COMMS | | STORAGE |
| & RECORDS | | people use | | messages, | | databases, |
| the state's | | apply, | | notices, | | file stores,|
| authoritative| | enrol, be | | channels | | the data |
| information | | recognised | | (see SIG 220)| | (Lesson 05) |
+--------------+ +-------------+ +--------------+ +--------------+
| | | |
+--------------+-------+-------+--------------+
|
+-----------v-----------+
| THE NETWORK |
| LAN + internet, DNS, |
| routing, encryption |
| (Lesson 02) |
+-----------------------+
|
reached by CLIENTS: the phones
and laptops members and nationals use
You do not need to operate any of these today. The point of naming them in the first lesson is that the rest of the course, and the rest of the speciality, hangs on this map. When a later lesson talks about provisioning an account, that is the identity service. When it talks about a recovery point, that is storage and backups. When it talks about routing and certificates, that is the network. The map turns a vague sense of "the systems" into a small number of named parts you can reason about.
Self-hosting versus the cloud
Every one of those system types raises the same question: whose machine does it run on? There are two broad answers, and the choice between them shapes almost everything else, including a good deal of what this speciality exists to do.
To self-host is to run a service on your own server, under your own control. You install it, you configure it, you decide how it is secured, you choose when it changes, and the data lives on machines that answer to you. To use the cloud is to rent the service, or the server it runs on, from an outside provider reached over the internet. The provider runs the machines, often handles much of the maintenance, and can give you a working service quickly without your owning anything.
Neither is simply better. They trade different things, and the honest way to see it is side by side.
SELF-HOSTED vs CLOUD: THE TRADE-OFF
| | SELF-HOSTED | CLOUD (rented) |
|----------------------|------------------------|-----------------------|
| Control | full: you decide all | limited: provider's |
| | configuration & change | terms and defaults |
| Sovereignty over data| data on your machines | data on theirs, under |
| | under your authority | their jurisdiction |
| Who maintains it | YOU do: updates, | provider does much |
| | security, backups | of it for you |
| Speed to get going | slower: you build it | fast: rent and run |
| Cost shape | your effort + hardware | a recurring rental |
| Dependence on others | low: stands on its own | high: relies on a third|
| | | party staying willing |
| If the provider fails| not your problem | can take you down or |
| or changes terms | (it is your machine) | lock you out |
Self-hosting buys CONTROL and SOVEREIGNTY at the price of DUTY.
The cloud buys CONVENIENCE at the price of DEPENDENCE.
The headline is plain. The cloud is convenient and fast, and for many small jobs it is the sensible choice. What it costs is dependence: your data sits on someone else's machines, under their terms and their jurisdiction, and if they raise prices, change their rules, suffer an outage, or decide they no longer wish to serve you, you are exposed. Self-hosting reverses that. It is more work, but the systems and the data stand on machines that answer to you alone.
Why a sovereign state often self-hosts, and what it then owes
For an ordinary business the trade-off above is mostly about cost and convenience. For a sovereign state it carries an extra weight, and that weight tips a small, serious Principality towards self-hosting more often than not.
The reason is sovereignty. A state that holds its register of nationals, its records, and its identity service on another party's cloud has, in a real sense, placed a piece of itself in someone else's hands. The provider could be subject to laws the Principality did not make, could be pressured, could change its terms, or could simply fail. For information that is close to the state itself, that dependence is hard to accept. Self-hosting keeps the Principality's systems, its data, and its decisions under its own control. That is control, the practical thing, and sovereignty, the principled thing, and for a non-territorial state whose substance is largely its information, they are not luxuries. This is why the Principality runs on self-hosted online services rather than renting its statehood from a provider.
But sovereignty is not free, and this is the part a member moving into the speciality must take to heart. When you run your own systems, no one else is going to keep them safe. The duties that a cloud provider would otherwise carry now fall to the Principality, which means they fall to the few capable, disciplined members who support those systems. There are three duties above all.
Maintain. A self-hosted system is not a thing you switch on and forget. It has to be watched, kept running, monitored for trouble, and documented so the force does not depend on one person's memory. A service that no one tends quietly rots.
Update. Software has flaws, and flaws get fixed in updates and patches. Most successful attacks exploit known holes that a patch had already closed. If you host it, you must keep it patched and current; the provider is not going to do it for you.
Secure. Every duty in CIS 201 now applies to the systems themselves, not only to how people use them. Access must be controlled, accounts guarded, configuration kept safe, data backed up and the backups tested. The wall around a non-territorial state is its security, and when the state hosts its own systems, building and keeping that wall is its own responsibility.
This is the bargain in one line: self-hosting buys control and sovereignty, and it is paid for in the discipline of maintaining, updating, and securing what you run. A force that wants the first must be honest about owing the second. The rest of CIS 210 is, in large part, the working detail of those three duties, and the speciality exists because someone has to discharge them.
The systems mindset
There is a habit of thought that separates a person who can only use systems from one who can help run them, and it is worth naming directly, because growing it is the real object of this course.
A user asks one question of a system: does it do what I need right now? That is a fair question, and for most members it is enough. Someone who supports systems learns to ask more. How is this built? What does it depend on? Who else relies on it? What happens if it stops, and how would we get it back? Where does its data live, and is there a good copy somewhere safe? Who is allowed to change it, and how would we know if something changed that should not have? That widening of the questions is the systems mindset: seeing a service not as a magic box but as a part with connections, dependencies, and consequences.
CIS 201 lived at the level of the careful user, the level of cyber hygiene, where the work is using systems safely. CIS 210 deliberately steps one layer below it, to how the systems themselves are shaped and kept alive. You do not need to be an expert to begin; you need to start seeing the estate as a small number of connected parts, each with a purpose, each depending on others, each owed maintenance and care. Every later lesson sharpens one corner of that view: the network in Lesson 02, accounts and identity in Lesson 03, keeping systems running in Lesson 04, backups and continuity in Lesson 05, hosting in Lesson 06, containers and virtualisation in Lesson 07, configuration and hardening in Lesson 08, documentation and automation in Lesson 09, and the conduct of someone trusted with elevated access in Lesson 10. Together they turn the map you have just drawn into something you can support responsibly, which, in a digital Principality, is a genuine contribution to its defence.
In Practice: a systems assistant draws the map
Corporal Okonkwo has just begun the Information Systems speciality and has finished this first lesson and nothing more. He has, deliberately, no administrative access to anything, because access follows appointment and his does not yet include it. His section runs a handful of the Principality's self-hosted services, and his appointment is simply to learn how they fit together so that he can help support them later.
Asked by his section commander to "make sense of what we run", he does not start by touching anything. He starts by drawing the map from this lesson. He lists the system types: an identity service that signs people in, the registers and records that hold the authoritative information, the everyday services people use, the storage underneath them, the communications channels, and the network that connects it all. Against each he writes the plain questions of the systems mindset. Which services depend on the identity service to let people in? Where does each service keep its data, and is that storage backed up somewhere safe? What reaches the internet, and what stays on the local network? Which of these are self-hosted, and what does hosting them oblige the section to maintain, update, and secure?
He cannot answer all of it yet, and he does not pretend to. But the exercise has changed how he sees the estate. Where a week ago there was a vague cloud of "the systems", there is now a small, named set of parts with purposes and dependencies, and a clear sense that running them is a duty the section owes, not a convenience it enjoys. He has operated nothing and been granted nothing. He has done the thing this lesson is built to make ordinary: he has stopped seeing the systems as magic boxes and started seeing them as a state's working parts, which is where the ability to support them honestly begins.
Check Your Understanding
- In your own words, explain the difference between a service, a server, and a client, and give one everyday example of each from your own use of Army or Principality systems.
- Name at least four of the kinds of system a non-territorial Principality depends on, and say in one short sentence what each is for.
- Give two reasons a sovereign state often chooses to self-host rather than use the cloud, and state the three duties that self-hosting then obliges it to carry out.
Reflection (write a short paragraph): Pick one service you use on Army or Principality business and apply the systems mindset to it. Beyond "does it work for me", what would you most want to know about how it is built, what it depends on, and what would happen if it stopped? Note one question you could not answer, and why knowing the answer would matter to the force.
Summary
- Nearly every system is built from three plain parts: a service (software that does a job), a server (a computer that runs services and answers requests), and a client (the phone or laptop a person uses to reach them).
- A non-territorial Principality depends on a small set of system types: an identity service for the accounts, the registers and records that make it a state, the services its people use, the storage that keeps its data, the communications that carry its messages, and the network that ties them together.
- Self-hosting means running services on your own machines under your own control; the cloud means renting them from an outside provider. Self-hosting buys control and sovereignty at the price of duty; the cloud buys convenience at the price of dependence.
- A sovereign state often self-hosts because so much of its substance is information, and keeping that information under its own control is a matter of control and sovereignty. In return it must maintain, update, and secure what it runs, because no provider will do it for the state.
- The systems mindset is the habit of seeing a service not as a magic box but as a part with purpose, dependencies, and consequences, asking how it is built, what it relies on, and what happens if it stops. This is the layer below the cyber hygiene of CIS 201.
- This lesson opens CIS 210 and draws the map the rest of the course fills in: the network (Lesson 02), accounts and identity (Lesson 03), keeping systems running (Lesson 04), backups and continuity (Lesson 05), hosting (Lesson 06), containers and virtualisation (Lesson 07), configuration and hardening (Lesson 08), documentation and automation (Lesson 09), and elevated access (Lesson 10). It builds on CIS 201 · Digital Security and Cyber Hygiene, leads on to CIS 220 · Identity, Access, and Records Security and CIS 310 · Cyber Incident Response and Continuity, supports HCR 220 · Emergency Preparedness and Civil Resilience (continuity), and shares the disciplined, defensive mindset of SIG 220 · Communications Security and Digital Discipline.
Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia