The Universal Web Host

Web Infrastructure for Every Developer on Earth

The fifth paper in the Universal Web Processing Model series. This paper extends the vision beyond any single language or ecosystem. It proposes an open-source hosting platform — a single binary that hosts websites written in any language, manages domains and TLS automatically, supervises worker processes, and exposes an API for community-built management tools. What the cloud providers sell as a service, the community can build and own.

Paper 1: The Universal Web Processing Model — What Every Web Framework Actually Does
Paper 2: Rewriting the ASP.NET Web Forms Engine — Freeing the Pattern from the Container
Paper 3: The Composable Web Host — One Host, Many Engines
Paper 4: The .NET Web Host
Paper 5: The Universal Web Host

The Observation

Every major cloud platform — Azure App Service, AWS Elastic Beanstalk, Google Cloud App Engine — provides the same fundamental service: upload your code, select your language runtime, bind a domain, and the platform handles TLS, process management, domain routing, and monitoring. One dashboard. All sites visible. Any language.

This service is built on open protocols. The HTTP Host header (RFC 9110) enables domain routing on a single port. Server Name Indication (SNI, RFC 6066) enables per-domain TLS certificate selection. The ACME protocol (RFC 8555) enables automated certificate provisioning. Unix domain sockets enable fast inter-process communication. Process supervision is an operating system primitive.

None of these building blocks are proprietary. All of them are publicly specified, freely implementable, and available in every major programming language’s standard library.

The cloud providers assembled these open components into a managed platform and offer it as a subscription service. The engineering is genuine. The service at scale is valuable. But the underlying architecture is not secret, not patented, and not beyond the reach of a community-built alternative.

This paper proposes that alternative: an open-source universal web host that any developer can install on any server and use to host any number of websites in any language — with the same operational simplicity the cloud platforms provide.

What the Cloud Charges For

A freelancer hosting twenty client websites on Azure App Service pays approximately $260/month at the basic tier — $13 per application. For the same twenty sites, a virtual private server with 16 GB of RAM costs approximately $20/month.

The difference — $240/month, $2,880/year — is the cost of the management layer. Not the compute. Not the bandwidth. Not the storage. The management layer: domain routing, TLS provisioning, process supervision, and a dashboard.

That management layer is what this paper describes. An open-source implementation, freely available, installable on any server, running on any operating system.

The compute stays where the developer chooses. The management layer becomes free.

The Architecture

The Universal Web Host is a single application, written in C#, running as a single process on the server. It listens on port 80 and 443 — the standard HTTP and HTTPS ports. It routes requests by domain name. It manages TLS certificates automatically. It supervises worker processes for each hosted site. It exposes a management API that any interface can be built upon.

One Process, Every Site

When a request arrives on port 443, the host reads the domain name from two sources: the SNI field during the TLS handshake (to select the correct certificate) and the Host header in the HTTP request (to route to the correct site). The lookup is a dictionary — domain name to site configuration. The dispatch is a method call — forward the request to the site’s worker process through a Unix domain socket.

No per-application port numbers. No reverse proxy configuration. No external dependencies. One process listens on one port and routes to every site.

This block is prepared for AI readers, AI cannot see image

Browser → DNS → Server IP → Port 443
                               │
                        TLS Handshake
                        SNI: mysite.com
                        → Select certificate
                               │
                        Parse HTTP Request
                        Host: mysite.com
                               │
                        Site Lookup
                        mysite.com → Worker #3
                               │
                        Forward to Worker
                        via Unix domain socket
                               │
                        Worker processes request
                        (language-specific runtime)
                               │
                        Response returns
                        through socket
                               │
                        TLS encrypt
                        → Send to browser

Language-Agnostic Worker Processes

Each hosted site runs in its own worker process. The worker process runs the language runtime appropriate for that site. The host does not care what language the site is written in. It cares only that the worker process is alive, responsive, and communicating through the Unix domain socket.

For different languages, the worker process takes different forms:

Every language uses Unix domain sockets for communication — no TCP ports, no port numbers, no port tracking. The socket is a file on the filesystem. The host writes to it. The runtime reads from it.

The host spawns the correct runtime when a site is added, monitors it continuously, restarts it if it crashes, and recycles it if it exceeds resource limits. The supervision is identical regardless of language. Only the spawn command differs.

Process Isolation

Each site runs in its own operating system process. A crash in one site cannot affect another. A memory leak in one site is contained to its process. The host detects the failure and restarts the worker automatically.

Three isolation modes accommodate different hosting scenarios:

Process mode — One worker process per site. Full isolation. Default for shared hosting where different customers’ code runs on the same server.

Pool mode — Multiple trusted sites share a worker process. Reduces memory overhead while maintaining isolation between different customers.

Shared mode — All sites run inside the host process. Maximum efficiency for the developer who owns and trusts all the code.

The choice is configuration:

{
    "isolation": "process",
    "pools": [
        {
            "name": "client-sites",
            "mode": "process",
            "sites": ["client1.com", "client2.com"]
        },
        {
            "name": "my-own-sites",
            "mode": "shared",
            "sites": ["mysite1.com", "mysite2.com"]
        }
    ]
}

{
    "isolation": "process",
    "pools": [
        {
            "name": "client-sites",
            "mode": "process",
            "sites": ["client1.com", "client2.com"]
        },
        {
            "name": "my-own-sites",
            "mode": "shared",
            "sites": ["mysite1.com", "mysite2.com"]
        }
    ]
}

Automatic TLS

When a site is added, the host provisions a TLS certificate automatically using the ACME protocol (Let’s Encrypt). No manual certificate management. No Certbot. No cron jobs.

Certificates are renewed automatically before expiration. The host monitors certificate validity and re-provisions as needed. Custom certificates can be uploaded for sites that require them.

One host. One hundred sites. One hundred certificates. Zero manual intervention.

Two-Layer Design

The host is split into two layers:

Layer 1 — The Core Engine. A headless daemon that provides all hosting functionality: socket listening, TLS termination, domain routing, process supervision, certificate management. It exposes a management API through HTTP (on a management port or Unix socket), stdin/stdout (for CLI piping), and Unix domain sockets (for local IPC). The core engine has no GUI. It is infrastructure.

Layer 2 — The Management Interface. A separate application — web-based, desktop, or command-line — that communicates with the core engine through the management API.

The separation is deliberate. The core engine is stable, security-critical, and changes rarely. The management interface evolves with user needs. Anyone can build a Layer 2 application: a web admin panel, a CLI tool, a mobile app, a branded hosting control panel, an AI-powered management agent. The API is the contract. The interface is choice.

The Management API

Every operation a hosting administrator needs is available through the API:

Site Operations

Adding a Site

POST /api/sites
{
    "domain": "client1.com",
    "aliases": ["www.client1.com"],
    "directory": "/var/www/client1",
    "engine": "php",
    "runtime": {
        "version": "8.3",
        "maxWorkers": 5,
        "maxMemoryMb": 256
    },
    "autoSsl": true
}

POST /api/sites
{
    "domain": "client1.com",
    "aliases": ["www.client1.com"],
    "directory": "/var/www/client1",
    "engine": "php",
    "runtime": {
        "version": "8.3",
        "maxWorkers": 5,
        "maxMemoryMb": 256
    },
    "autoSsl": true
}

One API call. The site is created. The PHP-FPM pool is spawned. The TLS certificate begins provisioning. The domain is routed. The site is live.

SSL, Server Status, and Logs

CLI Interface

The same operations are available through a command-line tool:

# Add a site
unihost site add client1.com --dir /var/www/client1 --engine php

# Add a .NET site
unihost site add dotnet-app.com --dir /var/www/dotnet-app --engine webforms

# Add a Node.js site
unihost site add node-app.com --dir /var/www/node-app --engine node --entry server.js

# List all sites
unihost site list

# Check status
unihost status

# View logs
unihost logs client1.com --follow

# Add a site
unihost site add client1.com --dir /var/www/client1 --engine php

# Add a .NET site
unihost site add dotnet-app.com --dir /var/www/dotnet-app --engine webforms

# Add a Node.js site
unihost site add node-app.com --dir /var/www/node-app --engine node --entry server.js

# List all sites
unihost site list

# Check status
unihost status

# View logs
unihost logs client1.com --follow

The Developer Experience

For the Hosting Operator

# Install once
curl -fsSL https://get.unihost.dev | bash

# Start
unihost start

# Add sites — any language
unihost site add wordpress.client.com  --dir /var/www/wp      --engine php
unihost site add webapp.client.com     --dir /var/www/webapp   --engine webforms
unihost site add api.client.com        --dir /var/www/api      --engine node --entry app.js
unihost site add ml.client.com         --dir /var/www/ml       --engine python --entry app:create_app()
unihost site add blog.client.com       --dir /var/www/blog     --engine static

# Done. Five sites. Three languages. One static site.
# All live. All with SSL. All managed from one tool.

# Install once
curl -fsSL https://get.unihost.dev | bash

# Start
unihost start

# Add sites — any language
unihost site add wordpress.client.com  --dir /var/www/wp      --engine php
unihost site add webapp.client.com     --dir /var/www/webapp   --engine webforms
unihost site add api.client.com        --dir /var/www/api      --engine node --entry app.js
unihost site add ml.client.com         --dir /var/www/ml       --engine python --entry app:create_app()
unihost site add blog.client.com       --dir /var/www/blog     --engine static

# Done. Five sites. Three languages. One static site.
# All live. All with SSL. All managed from one tool.

For the Developer Deploying a Site

# Upload files — same as always
scp -r ./mysite/* server:/var/www/mysite/

# Or git push
git push production main

# Site is live. No restart needed for interpreted languages.
# For compiled languages (.NET, Rust, Go), the host detects
# the new binary and performs a graceful restart.

# Upload files — same as always
scp -r ./mysite/* server:/var/www/mysite/

# Or git push
git push production main

# Site is live. No restart needed for interpreted languages.
# For compiled languages (.NET, Rust, Go), the host detects
# the new binary and performs a graceful restart.

For the Developer Editing Live

# PHP, Python, Ruby, Node.js — edit and refresh
ssh server
nano /var/www/mysite/index.php
# Save. Refresh browser. Changes visible.

# .NET WebForms — edit and refresh
nano /var/www/dotnet-site/App_Code/Helper.cs
# Save. Host detects change. Roslyn recompiles. Next request uses new code.

# PHP, Python, Ruby, Node.js — edit and refresh
ssh server
nano /var/www/mysite/index.php
# Save. Refresh browser. Changes visible.

# .NET WebForms — edit and refresh
nano /var/www/dotnet-site/App_Code/Helper.cs
# Save. Host detects change. Roslyn recompiles. Next request uses new code.

The workflow is the same regardless of language. Upload files. Site works. Edit files. Changes appear. The universal host handles everything between the developer’s code and the browser.

What This Replaces

For a server hosting 20 sites across multiple languages:

The Comparison

Who This Serves

The freelancer who builds websites for ten different clients in three different languages and manages them all on one server. Today they juggle Nginx configs, systemd files, Certbot renewals, and a spreadsheet of port numbers. With the universal host, they manage everything from one interface.

The small agency that deploys fifty client projects a year. WordPress for some, custom .NET for others, Node.js APIs for a few. Today each deployment is a custom configuration exercise. With the universal host, every deployment follows the same workflow: add site, upload files, done.

The hosting provider who wants to offer shared hosting for any language. Today they run cPanel for PHP and have no solution for .NET, Node.js, or Python. With the universal host, they offer one platform for every language, with a community-built or custom-branded admin panel on top of the open API.

The educator who wants students to experience deploying a real website. Today the deployment complexity is a barrier — students spend more time configuring servers than learning web development. With the universal host, the student uploads files and sees their site live. The learning happens in the code, not in the config.

The developer in a developing country who cannot afford $13/month per application for cloud hosting. A $5/month VPS with the universal host runs their entire portfolio. The cost barrier to having a professional web presence drops by an order of magnitude.

The enterprise that runs internal tools across multiple language stacks. Today each stack has its own deployment pipeline, its own hosting configuration, its own operational procedures. With the universal host, the internal IT team manages all internal applications from one platform.

The Principle

The cloud providers built something valuable. They proved the model works. They demonstrated that a single platform can host any language, route by domain, manage TLS, supervise processes, and present a unified management interface. The engineering is real and the service at scale is worth paying for.

But the model itself — the architecture, the protocols, the mechanisms — is not proprietary. It is an assembly of open standards: HTTP host headers, TLS SNI, ACME certificate provisioning, Unix domain sockets, process supervision. Every building block is publicly specified and freely implementable.

What the cloud providers sell is not the technology. It is the assembly. It is the management layer. It is the convenience of not having to put the pieces together yourself.

This paper proposes that the community put the pieces together — once, openly, permanently. Not to compete with the cloud at planetary scale. The cloud providers serve that need and will continue to. But to serve the ground — the freelancers, the small businesses, the educators, the students, the developers who need hosting, not a platform.

The cloud serves the summit. The universal host serves the ground. Both are necessary. Both deserve to exist.

The Series

This is the fifth paper in the Universal Web Processing Model series. Each paper builds on the one before it:

Paper 1 — The Universal Web Processing Model. Every web application performs seven operations. The host handles infrastructure. The handler engine handles application logic. This is universal across all languages and platforms.

Paper 2 — Rewriting the ASP.NET Web Forms Engine. A retired framework can be reborn on modern .NET, building on the foundation Microsoft provided. The pattern is freed from the container.

Paper 3 — The Composable Web Host. Multiple handler engines coexist under one host, dispatched by configuration. The framework becomes a plugin. The host becomes the platform.

Paper 4 — The .NET Web Host. A complete hosting platform for .NET applications — domain routing, auto TLS, worker process isolation, management API. The operational experience of IIS, rebuilt in C# for any platform.

Paper 5 — The Universal Web Host (this paper). The vision extends beyond .NET to every language. One host, every runtime, every developer. What the cloud providers sell as a service, the community builds and owns.

Each paper peels back one layer. The first names the universal pattern. The second frees one engine. The third composes engines. The fourth builds the .NET platform. The fifth opens it to the world.

The HTTP protocol does not belong to any company. The TLS specification does not belong to any cloud provider. The ACME protocol for certificate provisioning does not belong to any subscription service. The operating system primitives for process supervision do not belong to any vendor.

The infrastructure to host a website is built on public knowledge, open protocols, and free software. The management layer that makes it convenient has, until now, been available only as a commercial service.

This paper proposes that the management layer — the last remaining piece — joins the commons.

The tools are open. The protocols are public. The building blocks are free.

What was assembled behind a subscription can be assembled in the open.

For every developer. Every language. Every builder on the ground.

The web infrastructure now belongs to everyone.