Cosmos Server: a self-hosted gateway that puts authentication in front of every app

The problem Cosmos Server targets: apps that were never meant to face the internet

Most self-hosted applications ship with a login page and little else. Plex, Home Assistant, a personal blog, a wiki: each one is a separate authentication silo, and the moment you forward a port to reach it from outside, you own whatever vulnerability it has. Cosmos Server exists to sit between the internet and those applications. The README frames the goal as solving "the increasingly worrying problem of vulnerable self-hosted applications and personal servers", and the feature list reads like a checklist of the mitigations a single app usually lacks: multi-factor authentication, OpenID, forward-header auth, HTML login strategies, anti-bot detection, IP rate limiting and geo-blacklisting.

The audience is narrow but real. It is for someone who already has a server, a NAS or a Raspberry Pi running a handful of services and who wants one account and one entry point rather than five. It is not aimed at people who want to build applications, and it is not a hosting provider. The project describes itself as both a secure gateway and a server manager, which means it wants to own the reverse proxy, the container lifecycle and the storage layer at the same time.

How Cosmos Server works: reverse proxy, identity provider and SmartShield in one process

The repository layout confirms the architecture. A Go backend lives in src/, a React front end in client/, and the module file pulls in go-acme/lego for certificate issuance, ory/fosite for OAuth and OpenID, pquerna/otp for TOTP, oschwald/geoip2-golang for IP geolocation, go-chi/httprate for rate limiting, and the Docker client libraries for container control. That is a reverse proxy with an identity layer bolted into the same binary rather than a proxy that delegates auth to a sidecar.

SmartShield is the part worth understanding before you install anything. The README describes it as technology that "automatically secure your applications without manual adjustments", and lists anti-bot and anti-DDoS strategies plus TCP protection for FTP, SSH and games. The Go dependencies support that description: geo-blacklisting needs the GeoIP database, rate limiting needs a counter keyed by IP, and TCP protection implies the proxy inspects traffic before it reaches the upstream service. The trade-off is that automatic protection is a default you did not choose. A throttling rule tuned for a web app can interfere with a long-lived connection, and the README does not document per-application exemptions in the excerpt available. Treat SmartShield as a starting point you will have to tune, not a setting you can ignore.

The rest of the stack is assembled from other projects rather than written from scratch. Backups use Restic, network storage uses RClone, and the module file shows NATS for internal messaging and SQLite or PostgreSQL for persistence. That is a pragmatic choice: Cosmos Server is an integration layer, and its quality depends on how well those pieces are wired together.

Installing Cosmos Server and routing your first application through it

The README points to cosmos-cloud.io for documentation and offers a live demo of the UI at cosmos-cloud.io/cosmos-ui. The repository ships a docker.sh helper script and a dockerfile, and the project publishes an image on Docker Hub under azukaar/cosmos-server. The README does not print a full docker run command in the excerpt available, so check the documentation site for the current invocation rather than copying a flag from a blog post.

Once the container is running, the workflow described in the README is: install Cosmos on your server, then connect to your applications through it. In practice that means adding an application entry in the UI, pointing it at either a container name, another host, or a static folder, and letting Cosmos issue a certificate and place the login in front. The README states that automatic HTTPS is handled for you, and go-acme/lego in the module file is the library that does it, which means you need a domain that resolves to the server for certificate issuance to succeed.

A docker-compose file is the manual path the README mentions alongside its app store. The repository includes docker-compose support in the container manager, so an existing compose file can be imported rather than rewritten. The README does not print a sample compose file in the excerpt available, so copy the one you already run and import it through the UI. After import, the container appears in the Cosmos container manager, and you attach a route and an auth policy to it from the UI. The README does not document rollback of an application configuration, so keep your own copy of any compose file you import.

Where Cosmos Server gets in the way

The honest limitation is that Cosmos Server wants to be the front door for everything, and anything that cannot go through an HTTP reverse proxy is awkward. The README lists TCP protection for FTP, SSH and games, which acknowledges the problem, but a reverse proxy is still the wrong tool for protocols it does not understand natively. If your setup is one SSH box and nothing else, you are adding a large Go service, a React front end and a database to solve a problem sshd already solves.

Second, the project is on a fast release cadence. The most recent tagged releases are v0.23.4 on 2026-08-30 and a series of 0.24.0 beta builds on 2026-09-05, and the repository contains an unstable channel. Running beta builds on the machine that fronts all your services means a bad release takes everything down at once, which is a different risk profile from running a beta of a single app. Pin a stable tag and read changelog.md before moving.

Third, the feature list is broad, and breadth is not the same as depth. Storage manager, parity disks, MergerFS, RClone remotes, backups, CRON, monitoring, VPN: each of these is a project in its own right, and the README's comparison table against Unraid, YunoHost, CasaOS and Cloudron is the project's own marketing rather than an independent evaluation. If disk management is your main concern, a purpose-built NAS system will have more documentation and more people who have hit the same failure.

Cosmos Server compared with CasaOS and Unraid

The README's own comparison table is the place to start, with the caveat that it is written by the project. It positions Cosmos against Unraid, YunoHost, CasaOS and Cloudron, and the row that matters most is reverse proxy: Cosmos marks it present, Unraid and CasaOS absent, YunoHost present. That single row explains the design difference. CasaOS is primarily a dashboard and app launcher for Docker containers; it gives you a friendly UI over Docker but does not put an authentication layer in front of what it launches. Unraid is a storage-first operating system with Docker and VM support, and its proxy story is something you add yourself.

Cosmos Server inverts that. It assumes the proxy and the identity provider are the centre of the system, and the app store, container manager and storage features hang off that centre. If your problem is "I have ten services and ten logins and I am tired of forwarding ports", the Cosmos approach addresses it directly. If your problem is "I have eight drives and I want parity and a share", a NAS operating system is the better fit, and you can still put a reverse proxy in front of it later.

Proxmox is a different comparison again, and one people search for. Proxmox virtualises machines and containers; Cosmos Server manages applications on a host you already have. They are not substitutes, and running Cosmos inside a Proxmox VM is a normal arrangement.

Maintenance, upgrade cost and the licence question

The last push to the default branch was on 2026-09-05, and the repository is not archived, so the project is being worked on. That also means the surface you maintain is larger than a single-purpose proxy: a Go binary, a React client, a database, and integrations with Restic, RClone, NATS and the Docker daemon. Upgrades are not just a new image tag if a release changes how applications or certificates are stored, and the changelog is the file to read first.

The licence is the item I would resolve before deployment. GitHub reports the licence as NOASSERTION, meaning it could not match the LICENCE file in the repository root to a known identifier. The README does not state the terms. That file is short and worth reading yourself, particularly if you plan to run Cosmos Server for a business or bundle it into something you distribute. I am not a lawyer and this is not legal advice; the point is that the answer is one file away and the repository metadata does not give it to you.

Editorial conclusion

Adopt Cosmos Server if you already run several containers and want one login, automatic HTTPS and bot filtering in front of all of them instead of patching each app. Do not adopt it if you want a hypervisor or a NAS operating system: it is a gateway and manager that sits on top of an existing Linux host, not a replacement for Proxmox or Unraid. Before committing, verify on your own hardware that the SmartShield defaults do not break a latency-sensitive service such as a game server, and read the LICENCE file in the repository root, because GitHub reports the licence as NOASSERTION and the README does not spell out the terms.

Frequently asked questions

Official sources

1. azukaar/Cosmos-Server on GitHub
2. Issues
3. Project website
4. README
5. Releases