Cosmos Server: A Self-Hosted Gateway That Bundles Auth, Proxy and Anti-Bot

The Problem Cosmos Targets: Exposed Self-Hosted Apps

The README states the project aims to solve "the increasingly worrying problem of vulnerable self-hosted applications and personal servers." That is a specific complaint, not a general one. A typical home setup grows by accretion: a Plex container, a HomeAssistant instance, a blog, each published on its own port or subdomain, each with its own login form or none at all. The person running it becomes the de facto security team for every service they installed.

Cosmos approaches that by inserting itself as the entry point. Applications are reached through Cosmos rather than directly, so authentication, rate limiting and bot detection are applied at the gateway instead of being configured per app. The README frames the target audience broadly: a server, a NAS, or a Raspberry Pi. That covers a wide range of hardware, and it also implies the project expects to run on modest machines.

The audience is therefore people who want one place to manage users, certificates and exposure, and who are willing to route traffic through a component they did not write. Anyone who prefers to keep each service independently reachable and independently secured is not the intended user.

What the Gateway Actually Does: Proxy, Auth and SmartShield

The reverse proxy is the load-bearing piece. The README describes it as targeting containers, other servers, or static folders and SPAs, with automatic HTTPS and a UI for configuration. That means Cosmos holds the TLS certificates and terminates connections, then forwards to a backend it resolves by container name or address.

Authentication sits in front of that. Cosmos acts as an authentication server with multi-factor authentication and multiple strategies: OpenId, forward headers, and HTML. Forward headers matter because they let a backend trust an identity that Cosmos has already verified, rather than asking the user to log in twice. The HTML strategy covers applications that cannot consume headers and need a login page injected in front of them.

SmartShield is the part with no direct equivalent in a plain nginx setup. The README says it automatically secures applications "without manual adjustments" and includes anti-bot and anti-DDOS strategies: common bot detection, IP based detection, variable timeouts and throttling, IP rate limiting, geo-blacklisting, and TCP protection for protocols such as FTP, SSH and games. The TCP layer is worth noting because it extends the shield beyond HTTP, which most reverse proxies do not attempt.

The surrounding modules are storage management with Parity Disks and MergerFS, RClone-based network storage, a VPN, Restic-backed incremental encrypted backups, monitoring with alerts, CRON scheduling, and an app store with installers and update checks. The README explicitly claims modularity, so features such as Docker, databases or HTTPS can be left off.

Deployment: Docker, the App Store, and Existing Containers

The README points to a Docker Hub image, azukaar/cosmos-server, as the distribution channel, and the repository ships a CircleCI build badge for CI. That tells you the supported path is a container, not a package in a distribution repository.

Two installation routes are named. The first is the App Store, described as offering simple installers, automatic updates and security checks. The second is manual: importing docker-compose files or using the docker CLI directly. The README states these work alongside each other, so an existing compose stack does not have to be rewritten to sit behind Cosmos.

Once running, the web UI is the primary control surface, reachable from any device according to the README. The terminal is also supported, though the README does not list specific command names in the material available here. Configuration is therefore mostly done through the interface rather than by editing files, which is a deliberate trade: fewer text files to version, but also less to diff and review before an upgrade.

What the supplied material does not contain is a concrete docker run invocation, a compose example, or a list of environment variables. Anyone evaluating this should read the documentation site at cosmos-cloud.io/doc for the exact mount points and required ports before assuming a one-line install.

Where Cosmos Server Is the Wrong Choice

The release history is the clearest warning. The three most recent releases listed are v0.24.0-unstable007, v0.24.0-unstable006 and v0.23.4. Two of the three are explicitly labelled unstable beta builds, published within about an hour of each other. A project shipping at that cadence is moving fast, and a self-hosted gateway sits directly in the request path for every service behind it. If it breaks after an update, everything behind it becomes unreachable at once.

The architectural trade-off is also real. Cosmos concentrates authentication, TLS termination, proxying and traffic filtering into a single process. That is the point, but it means Cosmos becomes a single point of failure and a single point of compromise. A bug in the gateway is not a bug in one application; it is a bug in front of all of them. Users who already run a hardened reverse proxy with a separate identity provider may see the consolidation as a downgrade in isolation, even if it is an upgrade in convenience.

Finally, the licence. GitHub reports the licence as NOASSERTION, meaning the repository's licensing could not be matched to a known SPDX identifier. The supplied material does not include the licence text. Anyone planning to build on Cosmos, redistribute it, or run it commercially needs to read the actual licence file in the repository rather than infer terms from the project's open source framing.

Compared With YunoHost, Unraid and Cloudron

The README includes a comparison table against YunoHost, Unraid, CasaOS and Cloudron. In that table Cosmos is marked as having a reverse proxy, container management, and the other categories, while the alternatives are marked with a mix of yes, no and partial asterisks. For example, Unraid is shown without a reverse proxy, YunoHost with one but without container management, and Cloudron with a partial mark for reverse proxy.

The meaningful difference is not the checkmarks. YunoHost is built around packaged applications installed and managed through its own system, which gives strong integration but ties you to what has been packaged. Unraid is centred on storage arrays and NAS management, with application hosting as a secondary concern. Cloudron is a hosted-style application platform with a subscription model behind it.

Cosmos sits closer to the Cloudron end of the spectrum in ambition (identity, apps, backups, monitoring) but is distributed as a self-hosted Docker image. The distinguishing piece is SmartShield. None of the named alternatives in the table are described as shipping an anti-bot and anti-DDOS layer with TCP protection built into the same product. That is the feature to evaluate if you are choosing between them, and it is also the feature most likely to cause unexpected breakage.

Upgrade Cost and Maintenance Burden

Cosmos is not a set-and-forget component. It manages containers, certificates, users, backups and firewall-like rules, and each of those has its own failure mode. The App Store's automatic updates mean application containers change underneath you, and the release cadence of Cosmos itself means the gateway changes too. Both moving at once makes it harder to attribute a regression.

Backups are handled with Restic, described as incremental, encrypted and capable of remote targets. That is a reasonable foundation, but backups of application data only help if the Cosmos configuration itself is also captured. The material does not state where Cosmos stores its own state or how to restore it, so that is a question to answer before relying on the backup module for disaster recovery.

The licence question feeds into maintenance cost as well. With NOASSERTION reported, you cannot assume the same obligations or freedoms as a permissively licensed project until you read the file. If your organisation has a policy on licence review, this belongs in that queue before deployment, not after.

Who Should Adopt Cosmos Server

Adopt it if you run several web applications on one machine, you are comfortable with Docker, and the alternative is a hand-built stack of nginx, certbot, an SSO provider and a rate limiter that you maintain yourself. The consolidation is the value proposition, and the SmartShield layer is the part you cannot easily replicate with a few config files.

Do not adopt it as the front door for a production service that needs predictable release timing. The unstable beta releases in the recent history are a signal about how the project is currently developed. Do not adopt it either if you only need a reverse proxy, since a smaller dedicated tool will have a smaller blast radius and fewer moving parts.

Before committing, verify three things against the documentation site: the exact Docker run or compose configuration including volumes and ports, whether the SmartShield defaults interfere with any API client, webhook or non-browser traffic you depend on, and the contents of the licence file. The first two are operational, the third determines whether you can use it the way you intend to.

Editorial conclusion

Cosmos Server suits self-hosters who already run several web apps on one box and would rather configure a gateway once than maintain nginx, an SSO provider and a bot filter as three separate projects. It is the wrong tool if you need stable tagged releases for production, because the recent release list is dominated by 0.24.0-unstable builds, or if you want a pure reverse proxy and nothing else. Before adopting it, check the repository licence file directly, since GitHub reports NOASSERTION, and confirm that the SmartShield defaults do not block any API client or webhook you depend on.

Official sources

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