EdTech hosting becomes tangible when every part of a school’s digital environment works together. In our Munich reference project, the “Cosmo” school server for MOS Munich brings a Moodle 5.x instance, 55 custom plugins, local AI, and additional services onto one well-sized machine. Docker provides the container layer, while our GPUQ queue coordinates access to a single GPU. The result is an ecosystem we develop, host, and operate as Panomity.
What does EdTech hosting mean for a school?
EdTech hosting means running the learning platform, custom educational software, AI services, and supporting tools on infrastructure sized and managed for the school. In our Munich reference project, one EL9-based server combines Moodle, Docker services, local AI, authentication, and web operations while keeping student data on that server.
That is why we look at the whole stack. The base is an EL9 server. CyberPanel and OpenLiteSpeed handle the web environment. Docker containers package the self-hosted services. Moodle provides the learning platform, and custom modules extend it for teaching and organisation. Authentication protects access where a service is not public. A GPU supports local AI, and GPUQ makes that limited resource usable across different applications.
How did one server become a digital ecosystem?
The “Cosmo” reference server hosts the Moodle 5.x instance “mos Kurse” and its 55 in-house plugins. Around it, Docker runs local AI and practical supporting services. This architecture turns one physical system into several clearly defined service layers, each with a specific task and a shared operational context.
The plugin portfolio shows why the platform cannot be reduced to generic course pages. It includes German-language teaching activities such as Debatten-Dojo, Konjunktiv-Runner, Redewerkstatt, and Zitier-Schmiede. Politics and society is represented by the PuG learning journey, a local PuG AI helper, and an impact dashboard. Other plugins support navigation, room booking, course generation, feedback, planning, exports, and gamification.
The infrastructure around Moodle is equally varied. OnlyOffice, Vaultwarden, n8n, Perplexica, Open Notebook, and the access-protected OpenClaw assistant portal are self-hosted at the location. Ollama provides local language models. Speaches supplies local speech recognition and speech output with CUDA. GPUQ sits between AI requests and the GPU. One server therefore supports learning, organisation, and AI without turning those functions into unrelated hosting projects.
| Layer | Components | Role in the ecosystem |
|---|---|---|
| Server and web | EL9, CyberPanel, OpenLiteSpeed | Provides the operating base and web environment |
| Service packaging | Docker containers | Provides the framework for self-hosted services |
| Learning platform | Moodle 5.x “mos Kurse,” 55 custom plugins | Delivers courses, tailored activities, and organisational tools |
| Local AI | Ollama, Speaches, GPUQ | Handles text, vision, speech, and queued GPU jobs locally |
| Supporting services | Perplexica, Open Notebook, OpenClaw, n8n, OnlyOffice, Vaultwarden | Adds AI search, a notebook alternative, protected assistance, and other services at the location |
Docker gives each service a clear place
“One server” does not mean one large, inseparable application. Docker provides containers for the individual services. This keeps their roles visible and makes the stack understandable at an operational level. Moodle remains the centre of teaching, while AI endpoints and supporting applications run alongside it. CyberPanel and OpenLiteSpeed provide the surrounding web infrastructure on the same EL9 base.
Why does one GPU need its own queue?
A GPU can serve several AI applications, but their jobs must be coordinated. Our GPUQ software places requests in a queue, shares one GPU fairly among services and plugins, and exposes job status. This lets text, vision, and speech features use the same local hardware without each requiring a dedicated GPU.
Ollama listens locally on port 11434 and runs language models for chat and text tasks. Speaches uses CUDA for local Whisper speech recognition and speech output. GPUQ is the scheduling layer. It does not replace those AI services; it decides how jobs reach their shared hardware resource.
Local AI connects directly to educational workflows
The Moodle plugins use these components for defined tasks. The mosKI course bot combines Ollama, Speaches, and Whisper. Control AI provides central AI control. Image OCR uses Ollama Vision. The oral examination simulation uses Ollama, while Debatten-Dojo combines Ollama with Whisper for spoken debates. The PuG learning journey and local PuG AI helper send feedback work through GPUQ and Ollama.
This is an important architectural boundary. Moodle owns the learning activity and its context. The self-hosted AI services perform the requested processing. GPUQ manages access to the shared accelerator. Each layer has a clear responsibility, yet the student experiences one activity inside the learning platform.
How do 55 Moodle plugins change the platform?
Custom Moodle plugins turn subject-specific and organisational requirements into functions inside the existing learning environment. On “mos Kurse,” 55 in-house developments cover teaching activities, politics and society, administration, gamification, and local AI. The number matters less than the shared principle: software follows a defined school workflow.
Activity modules can guide a concrete learning process. The PuG learning journey, for example, has its own data model for stations, solutions, drafts, feedback, and progress. Organisational local plugins solve different problems, including simplified course navigation, room check-in, reminders, course generation, and exporting submissions. Both types extend Moodle, but they work at different levels of the platform.
The portfolio also connects didactics with infrastructure. An oral examination simulation needs a learning design in Moodle and a local model behind it. A spoken debate needs an activity, speech recognition, and language processing. The software should provide feedback that helps learners continue their own work. It should not become an automatic answer machine.
Why choose EdTech hosting on the school server?
Self-hosted EdTech hosting keeps student data on the school server and removes the need for US cloud AI. That gives the school technical data sovereignty, supports a clear GDPR-oriented approach, and makes the deployed infrastructure visible. A shared, well-sized server also creates a concrete basis for controlling operating costs.
Data sovereignty is an architectural decision
In this setup, Ollama, Whisper through Speaches, and the Moodle plugins run on the school server. Student data does not leave that server for AI processing. The point is not a vague promise about “private AI.” The processing location and the participating services are identifiable parts of the architecture.
Self-hosting also makes dependencies explicit. The school environment does not require US cloud AI for its local text, image, and speech functions. Panomity can connect the learning activity, model service, queue, and hardware within one hosted system. This is what data sovereignty looks like at implementation level.
Cost control starts with a visible stack
Cost control starts with a defined architecture. In the reference project, one well-sized server, Docker, and one shared GPU support the ecosystem. GPUQ lets multiple AI features use that GPU through one queue. The services retain distinct roles while sharing the same operating base, so the deployed resources stay visible.
What does our WordPress work add to the picture?
Our development and hosting work extends beyond Moodle. Panomity DarkWeb Press v8.1.2 is our WordPress plugin for checking whether passwords have been compromised on the dark web. It forms the basis of the Panomity Darkweb Gateway. Panomity WP Cache is our own caching plugin, and we centrally operate and manage many customer sites through a MainWP hub.
These products are not school plugins, but they show the same working perspective: we develop software and also operate the environments around it. Code, hosting, and ongoing platform management are connected responsibilities. For an EdTech project, that matters because a custom feature is only useful when its runtime environment and dependencies are available.
Where else does this architecture prove useful?
GPUQ also runs on the Panomity server behind CMS4VR, our virtual-tour platform. Its self-hosted AI concierge uses Ollama and Whisper speech-to-text. CMS4VR also works with DepthAnything V2, Apple SHARP, and Dollhouse. The connection is practical: the queue that coordinates school AI jobs also supports AI work in a different hosted product environment.
You can explore that platform in our articles about the self-hosted AI concierge for virtual tours and the Matterport alternative for 3D tours and 360-degree photos. Both show how local AI infrastructure can sit behind a specialised application rather than appearing as a detached chatbot.
The school project also documents its work publicly. The “AI in school” series from MOS Munich provides the school-side view. Our perspective here is the development and hosting layer: how Moodle, custom plugins, containers, AI services, and hardware become one technical system.
What should a school server really provide?
A school server needs more than storage and a web interface. It needs an operating base, a web stack, Docker containers, access protection, and resource coordination. For local AI, it also needs suitable GPU capacity and a queue that keeps competing jobs transparent and manageable.
In our reference architecture, EL9, CyberPanel, and OpenLiteSpeed form the base. Docker gives services defined places. Moodle and its plugins provide the educational layer. The access-protected OpenClaw portal shows where authentication belongs in the stack. Ollama and Speaches perform AI tasks, and GPUQ provides the shared queue and status. This division makes the ecosystem understandable without pretending that the underlying technology is simple.
The decisive result is the combination. A single well-sized server can support a complete school EdTech ecosystem when the services are designed as parts of one architecture. That does not mean every school needs the same plugin list. It means learning requirements, software, hosting, privacy, and hardware should be planned together.
Frequently asked questions
Can one server run a complete school EdTech ecosystem?
Yes. In our Munich reference project, one well-sized EL9 server runs Moodle, Docker containers, local AI, and supporting services. A single GPU is shared through GPUQ. The architecture works because each component has a defined role and the services are planned as one hosted ecosystem.
Why use Docker on a school server?
Docker gives the services around Moodle separate containers on the same server. In the reference stack, it supports local AI and additional self-hosted tools alongside the learning platform. This separation makes the role of each component clearer while allowing the ecosystem to share one EL9-based infrastructure.
What does GPUQ do?
GPUQ is Panomity’s self-developed GPU job queue. It shares one GPU fairly among AI services and Moodle plugins, places jobs in a queue, and provides status information. Ollama and Speaches perform the actual language, vision, or speech work; GPUQ coordinates their access to the shared hardware.
Do student data need to leave the school server for AI?
No. The reference architecture runs Ollama, Speaches, GPUQ, and the connected Moodle plugins locally on the school server. Student data stay on that server, so the AI workflows do not require a US cloud AI service. This makes the processing location a deliberate part of the privacy architecture.
What does Panomity provide for EdTech projects?
Panomity combines development and hosting. We build custom Moodle software and operate the server environment, Docker services, and local AI infrastructure around it. Our work also covers WordPress and VR systems. This lets us plan application code, model services, GPU coordination, and hosting as connected parts of one project.
Build and host your EdTech ecosystem with Panomity
Panomity develops and hosts EdTech from Munich, including Moodle extensions, Docker services, and self-hosted AI infrastructure. If you want to connect learning software with an environment designed to operate it, explore our hosting, IT security, and VR services and contact us through Panomity.
0 Comments