Eine Plan9 Installation wird durch mehrere Serverinstanzen repräsentiert. Diese Server können, müssen aber nicht auf physikalisch unterschiedlichen Computern laufen. In einem Plan9 System existieren meist vier verschiedene Instanzen.
Ein CPU-Server existiert einzig und allein um CPU- oder IO-gebundene Aufgaben zu erledigen. Da er viel Rechnen muss, sollte ein CPU-Server mit schnellen Multi-Prozessoren und viel Arbeitsspeicher ausgerüstet sein. Er ist die Instanz im System, die am wirklich Rechenleistung benötigt. Der CPU- und der FS-Server sollten untereinander eine schnelle Verbindung besitzen, damit zu berechnende Daten oder berechnete Daten schnell gelesen oder geschrieben werden können. An einem CPU-Server hängt keinerlei Peripherie. Ein Betrieb ohne Festplatte ist möglich und natürlich kann es in einem Plan9 Netz auch beliebig viele CPU geben. Um sich mit einem Plan9-CPU-Server zu verbinden benutzt man den Befehl cpu. Dieser macht vom Grundsatz her nichts anderes, als bestimmte Teile des eigenen Namensraum in den CPU-Server zu montieren. Somit arbeite man nach Ausführung des Befehls zwar mit den eigenen Ressourcen, jedoch nun auf dem Prozessor des CPU-Servers.
Der FileSystem-Server ist die einzige Instanz im Plan9 Netz, das Daten persistiert. Keine andere Maschine sonst speichert Daten permanent ab. Wie nicht anders zu erwarten, antwortet auch der FS-Server auf Anfragen über das 9P-Protokoll. Er existiert einzig und allein um Dateien auszuliefern. Traditionell speichert er nach dem WORM (WriteOnceReadMany) Prinzip und beinhaltet mehrere Caching-Stufen. Zuerst werden Daten ins den Arbeitsspeicher geschrieben und anschließend auf Festplatten zwischengespeichert, bis sie letztendlich auf einer Optical-Disk oder einem Tape landen. Die Wartung eines FS-Servers wird nur über die physikalische Konsole vorgenommen.
Wie schon erwähnt können Server stand-alone laufen oder aber mit auf anderen Maschinen installiert sein. Ein AUTH-Server wird in Plan9 Netzen auch gerne auf einem CPU-Server mit installiert. Ein AUTH-Server dient der Autorisierung von Verbindungen zwischen einem Server und einem Rechner und dient zur Bestätigung der Identität von Benutzer und Rechner. Dies impliziert, dass sich nicht jeder Rechner z.B. mit einem CPU-Server verbinden darf. Man muss also explizit Rechner und Benutzer in die Autorisierungs-Tabellen eines AUTH-Servers eintragen. Außerdem ist es möglich, Domänen zu verwalten. Um diese Authentifizierung zu realisieren, besitzt jeder Rechner einen insgesamt 132 Bit langen DES-Schlüssel, welcher sich aus einem 56-Bit-Schlüssel für den Rechner selbst, einer 28-Bit Authentication-Id des Benutzers und einem 48-Bit Authentication-Domain-Namen zusammensetzt. Die Authentifizierungsmechanismen laufen ziemlich analog zu dem einer Kerberos Authentifizierung. Passwörter werden niemals über das Netz gesendet, es werden ausschließlich Tickets für autorisierte Anfragen vergeben.
Das Terminal ist die einzige Benutzer-Schnittstelle zu einem Plan9-System. Von einer Unix-Betrachtungswiese aus gesehen, ist es zu Hälfte ein X-Terminal und zur anderen Hälfte eine Workstation, denn es bietet mehr als eine Schnittstelle und wie es ein X-Terminal tut, aber weniger als eine Workstation. Ein Texteditor z.B. läuft zwar auf dem Terminal, würde man jedoch etwas kompilieren, tut man dieses auf dem CPU-Server. Heavy jobs werden also nicht auf dem Terminal selbst, sondern auf einem CPU-Server ausgeführt. Dies führt dazu, dass ein Terminal selbst keinen schnellen Prozessor oder viel Arbeitsspeicher benötigt. Vom Grunde her ist jedes Terminal gleich, erst durch die Verbindung mit einem Fileserver wird es personalisiert. Somit kann sich ein User an ein beliebiges Terminal setzen, sich anmelden und mit einem FS-Server verbinden. Dies macht die Administration im Bezug auf Terminals sehr einfach. Auch Terminals werden wie CPU-Server sehr oft ohne eine Festplatte betrieben.
Das 9P-Protokoll ist ein zustandsorientiertes File-System-Protokoll. Auf sämtliche Ressourcen werden per 9P zugegriffen. Lokal gesehen, also an dem Punkt wo 9P Nachrichten eintreffen, sind diese Nachrichten Systemaufrufe im Kern. Praktisch werden 9P Nachrichten wie Funktionsaufrufe abgewickelt, es wird eine Nachricht mit einem Funktionsaufruf abgeschickt und man erhält als Antwort das Funktionsresultat dieses Aufrufs. Der Inhalt der Nachrichten wird vorzugsweise als Text übermittelt, da Text immer Text ist, unabhängig von der verwendeten Architektur. Man muss sich also nicht um die richtige Byteorder kümmern. Der Text wird in Unicode kodiert. Unicode, das mittlerweile zum Standard in einer internationalisierten Umgebung gehört, wurde speziell für Plan9 geschrieben. Zur Verdeutlichung: Der Plan9 Kernel besteht zur Hälfte aus der 9P Implementierung, was aufzeigt, wie essenziell 9P für das Designkonzept von Plan9 ist. Um mit 9P zu arbeiten benötigt man lediglich 16 Kommandos, wovon die wichtigsten hier einmal aufgelistet sind:
Plan9 ist durchwegs heterogen ausgelegt, es ist für den Benutzer oder den Entwickler völlig uninteressant auf welcher Plattform er sich befindet oder auf welcher Plattform der CPU-Server läuft mit dem er verbunden ist. Das Terminal kann somit ein x86 Rechner sein und der CPU-Server eine SPARC. Realisiert wird das ganze durch den Fakt, dass beim Kompilieren immer eine Cross-Kompilierung stattfindet. Auf jedem Plan9 System sind immer alle Compiler mit installiert und die entsprechenden Binaries werden an ihrer vorgesehenen Stelle abgelegt. Dies führt uns zurück an das Anfangs gezeigte Beispiel mit Bind: /bin/i386/ls und /bin/sparc/ls. Ausführbare Binärdateien liegen also immer für jede Architektur vor. Durch die Bindung im Namensraum, wird die für die Plattform entsprechende Binärdatei ausgeführt.