Sites & Virtual Hosts

When running web applications directly on the host operating system, you typically need a reverse proxy or web server (like Nginx, Apache, or Caddy) to route incoming HTTP traffic to the correct application daemon.

RasnuOS abstracts away the complexity of writing native configuration files. Through the Sites interface, you can orchestrate complex virtual hosts visually.

Automated Web Server Configuration

When you define a Site in RasnuOS, you specify the core parameters:

• Primary Domain: e.g., api.example.com
• Aliases: e.g., www.api.example.com
• Web Root Directory: Where the public assets or application entry point reside (e.g., /var/www/html/public, /home/app/dist, /srv/static).
• Upstream Process (Optional): If your application runs as a local daemon (e.g., a Node.js server on port 3000, a Go binary on port 8080, or a Python Gunicorn process on port 5000), you can bind the Site to proxy traffic to that specific internal address.

When you click Deploy, the RasnuOS Control Plane compiles a highly optimized, production-ready Nginx or Apache configuration file. This file is cryptographically signed and pushed to the Agent's queue.

The Agent pulls the payload, writes the configuration file to the host OS, verifies the syntax (e.g., nginx -t), and gracefully reloads the web server — all with zero downtime.

Reverse Proxying

Modern applications are most commonly written in Go, Node.js, Python, Ruby, Rust, or Java, running as persistent processes on specific internal ports.

You can configure a Site as a Reverse Proxy. The RasnuOS Agent configures the web server to forward all incoming traffic from ports 80 and 443 directly to your upstream application daemon, while automatically managing the X-Forwarded-For, X-Real-IP, and Host headers that your application needs to correctly identify client requests.