Janusec: an application gateway with WAF, ACME and OAuth2 in one box

One process in front of everything

The Janusec Application Gateway is described as providing fast and secure application delivery, and the function list reads like a shopping list of things a small team would otherwise bolt together one at a time.

The first function is unified security access to web applications, including HTTPS, OAuth authentication and security defence such as the WAF and CC protection. If the web application is deployed as Kubernetes pods, the gateway can also act as a Kubernetes ingress controller and give those pods the same access and security characteristics as an ordinary web application. The second is four-layer TCP and UDP forwarding for non-web applications, Kubernetes pods included.

The third is ACME automated certificates, described as free, for HTTPS access, with automatic renewal when a certificate expires. That one removes the single most common operational chore in a small deployment, since certificate renewal that is forgotten becomes an outage and certificate renewal that is scripted badly is worse.

What ties the list together is the delivery model. The configuration is web based, and the README lists fast delivery as web-based configuration as the first key feature. A config.json file still holds the database connection and the listen switch, but day-to-day configuration happens in the web console. For an operator who wants a security layer in front of a handful of applications, that is the whole pitch, and it is a narrower and more coherent product than a general-purpose load balancer.

The WAF, the CC defence and the CAPTCHA

The security defence section lists three things: a WAF, CC attack blocking, and CAPTCHA support. The README describes the WAF as blocking SQL injection, XSS and sensitive data leakage, and the repository carries two screenshots showing exactly those two cases, a SQL injection attempt and a sensitive data leak attempt being caught.

The CC defence is the more interesting one for a gateway. A CC attack is application-layer flooding rather than a volumetric one, so a network-level mitigation does not touch it, and the gateway sees it as a burst of requests that look legitimate individually. Putting the defence at the gateway means the application behind it never sees the traffic, and the CAPTCHA support is the escalation path for the requests that cannot be blocked outright.

The combination is coherent for the deployment Janusec describes. A WAF that sits in the path of every request, an anti-flood mechanism for the requests that are individually plausible, and a challenge for the ones that remain, is a layered answer rather than a single rule set. The WAF rules themselves are not described in the README, so the details of what is matched and how false positives are handled live in the documentation and in the product itself.

For a reader evaluating this, the screenshots are the honest part of the README, and they are of an attack being stopped, not of a configuration screen.

Authentication in front of the application

The authentication story is where a gateway earns its place in an internal-facing deployment. The README lists OAuth2 with WxWork, DingTalk, Feishu and Lark, which are the workplace messaging platforms used in China and are treated as identity providers. Then LDAP with authenticator two-factor, and CAS 2.0 for the older single sign-on protocol that many organisations still have.

The point of doing this at the gateway rather than in the application is that the application does not have to change. A set of internal services that need a login, none of which has an identity system of its own, gets one in front of them. That is a common enough situation, and the usual answers, either building auth into every service or putting a separate identity-aware proxy in front of them, are exactly what a gateway like this offers.

The other authentication-adjacent feature is cookie compliance management, provided from v1.4, which includes a cookie banner, consent management and cookie discovery. For a site that serves users in a jurisdiction with consent requirements, having the gateway enumerate the cookies an application sets and manage the banner in one place is a shortcut that removes a per-application implementation task.

The OAuth2 providers listed are the interesting detail, because they tell you who the project is aimed at, and they are also the compatibility limit: the list of identity providers is not open, so a team whose directory is elsewhere needs to check what is supported before planning around it.

GSLB, static cache, and what a self-managed edge means

Two of the later features are about delivery rather than security. Global server load balance, with a bundled DNS server, is provided from v1.4.2. Static content cache and acceleration is also in the list.

A bundled DNS server is the part to think about. GSLB is usually sold as a service, where a provider's anycast network decides where a request should go and the DNS answer reflects that. Janusec's answer is a DNS server you run, so the decisions about which site is closest and which is healthy are made by your own infrastructure. That is a coherent design for an organisation that already runs its own DNS and wants to avoid a third party, and it is a large operational surface for one that does not.

The static cache is the smaller, friendlier feature. A gateway that caches static content in front of an application is a cheap win for any site whose assets are cacheable, and it costs nothing but a setting.

The four-layer TCP and UDP forwarding rounds out the picture, and it is what makes the gateway a general ingress rather than an HTTP-only one. For an operator, the combination means one thing to deploy, one configuration interface, and one place where the certificate, the login and the firewall rules are set.

Building it, and the config that decides everything

The developer quick start is four steps. You clone the repository, edit config.json, build, and run as root.

git clone https://github.com/Janusec/janusec.git

The config file holds the database connection, and the README's example shows the fields:

"host": "127.0.0.1",
"port": "5432",
"user": "janusec",
"password": "123456",
"dbname": "janusec"

One detail is worth noting: Janusec will encrypt the password automatically, so the credential in the file is not left in the clear.

Then the build and the run:

go build
su
./janusec

The switch to root is not incidental. The requirements list nftables and systemd, and the gateway writes firewall rules, so it needs privilege. The same requirements list covers the platform support, Debian 9, 10 and 11 or later, CentOS and RHEL 7 and 8 or later with Debian 10 and 11 preferred, plus SQLite3 or PostgreSQL 10 through 14 or later for the development environment and for the primary node of a deployment. Go 1.19 or later is needed for development only.

For a release build the process is go build, then su, then./release.sh, and the resulting package lands in the./dist directory. Only Linux is supported, which is consistent with the systemd and nftables requirements.

The admin interface, and the primary node rule

The administrative interface is a web application served under the /janusec-admin/ path, and where you reach it depends on a single configuration switch, listen, in config.json.

When listen is false, the admin is reached over the port your application traffic arrives on, at http://your_primary_node_ip_address/janusec-admin/ for first use and https://your_application_domain_name/janusec-admin/ once a certificate is configured. When listen is true, the admin gets its own ports, 9080 for HTTP and 9443 for HTTPS, addressed by the primary node's IP address or domain name.

The second detail is the node rule. When using the primary node only, any application domain name can be used to reach the admin. But if you have one or more replica nodes, the README says you should apply for a separate domain name for the primary node. That is a small operational rule with a clear reason behind it, since the admin entry point has to be unambiguous when several nodes are serving traffic and the application domains are being used for something else.

The web administration files live in the ./static/janusec-admin/ directory, and the source of that interface is in a separate Janusec-Admin repository, with the front end written in Angular 9. Splitting the admin front end into its own repository is a common pattern for a Go binary that serves a compiled single-page application, and it also means the admin interface can be updated independently of the gateway binary.

Where Janusec is the wrong choice

The first wrong-tool case is an environment that is not Linux with systemd and nftables. Those are stated requirements, not preferences, and the gateway writes firewall rules as part of doing its job. A macOS developer machine or a Windows host is not a target, and a container without the right privileges is a fight.

The second is a team that already runs this layer well. A company with a mature ingress controller, a CDN and an identity-aware proxy has all of this already, and Janusec's value is that it is one tool instead of three, which is only an advantage if three tools is the problem.

The third is a global product. GSLB with a bundled DNS server is a self-managed approach to a problem that a global provider solves with anycast networks and a global DNS view. A service with users across continents is better served by a provider whose points of presence are already there, and by the time an organisation is running its own DNS, running its own global load balancer is usually a distraction from the product.

The fourth is a team that needs the admin interface to be the only interface. Everything is configured through the web console, which is a strength for a mixed-operations team and a limitation for one that wants configuration in version control.

AGPLv3, version 1.6.1, and a summer release

The licensing section is headed multiple licences, and it says the source files of the open source version are licensed under GNU AGPLv3. The project licence field on the repository shows a custom licence that GitHub cannot classify, so the LICENSE file is the place to check, and the AGPLv3 statement in the README is the concrete claim for the open source sources.

The AGPL matters for a gateway more than for most software, because a gateway is the component that terminates traffic and holds credentials, and a copyleft licence keeps modifications to it visible. For a company that wants to run it unmodified, that is a non-issue. For a company that intends to extend it, the obligation to publish the modified source is the thing to plan around.

On versions, the release list shows v1.6.1 on 2026-07-18, v1.6.0 on 2025-08-23 and v1.5.2 on 2025-03-08. The last push was on 2026-07-18, the same day as the newest release, so the repository is current, though the gap between the two most recent minor releases is a year, which suggests a steady but not rapid pace.

Support is offered through the product site, an email address at the janusec.com domain, and a QQ group, which is a fair indicator of where the project's user base is, and the project also maintains a Chinese-language site alongside the English one and an introduction presentation in both languages.

Editorial conclusion

Adopt Janusec if you want one Go binary to terminate TLS, apply a WAF, enforce a login in front of an application and keep the certificate renewed, especially if that application already runs in Kubernetes and you would rather use an ingress controller that also does authentication. Do not adopt it if your environment is not Linux with systemd and nftables, since those are hard requirements, and do not adopt it if you need a global CDN or a managed edge, because GSLB with a bundled DNS server is a self-managed answer to a different problem. Before you deploy, read the quick start on the documentation site, plan the database, since SQLite3 or PostgreSQL holds the configuration, and note the AGPLv3 licensing of the open source sources, which matters if you intend to modify the gateway itself.

Frequently asked questions

Official sources

1. Issues
2. Janusec/janusec on GitHub
3. Project website
4. README
5. Releases