On-premise WAF and bot protection: you choose where your traffic is processed
Klacos also runs on your own machines, as a Debian package or a Docker image. Your own server room, your hosting provider, the country you pick or a client’s network: you decide where your visitors’ requests are handled. You get the same web application firewall, the same bot management, the same caching and the same analytics as the managed service. Install the console as well, and your logs, analytics and keys stay entirely on your infrastructure.
Protecting a site also means knowing where its traffic goes
A protection service run by someone else sees all of your traffic. It keeps your logs, and often the private keys to your certificates. For a lot of teams, that’s not a detail.
A hosting provider doesn’t want its customers’ sites going through yet another supplier. A team in a regulated sector has to say where its traffic is processed, where its logs live and who can read them. An internal application has no business on shared infrastructure. As long as your protection runs somewhere else, every audit, every contract and every customer question about where data sits sends you back to someone else.
The same service, on your machines
A Debian package or a Docker image
It works on its own from day one
Cut off from the console, it carries on
Connected to a console with two settings
No inbound port to open
The console too, if you want it
The version you run does the same job as the managed service: protecting your site from bots and attacks, keeping it fast and available, and analysing its traffic. A new instance starts by observing and blocks nothing: you see your traffic as it is, then you decide, and you enforce one step at a time. Our page on how bot detection works walks through that path, from request to decision.
What you keep, and what you take on
Running Klacos yourself means deciding where your traffic is processed. In return, running it becomes your job. Look at both columns before choosing between this and the managed service.
What you keep
- your machines and your hosting provider, which don’t change;
- your network: your visitors’ requests only travel through it;
- your data: logs, analytics and settings stay on your servers when the console runs there too;
- the private keys to your certificates, on the proxy’s machine;
- the timing: you decide when a new version goes in.
What you take on
- keeping your instances available, and the console if it runs on your side;
- installing updates;
- securing the machines they run on;
- backing up your configuration files and the console’s data;
- monitoring, built on the metrics and health endpoints each instance exposes;
- capacity: machines sized for your traffic.
With the managed service, run in the European Union, the second column is our job: you point your domain at it and we run the rest.
What stays on your machines, and what leaves them
Always on the proxy’s machine
- the private keys for the certificates it obtains and renews;
- the access log, when you turn it on;
- the token used to purge the cache.
Sent to the console, once connected
- traffic events: every request and every connection, enough to judge visits and build your analytics;
- nothing else, and if the console runs on your side, nothing leaves your infrastructure.
A certificate you import through the console is stored there encrypted, then passed to the instance over its channel. If you’d rather your keys never left the proxy’s machine, let the instance obtain and renew its certificates itself.
An instance you run like the rest of your estate
Monitoring
Logs
Updates without downtime
Several instances
What running it yourself doesn’t do
Better to know before you install anything.
- One instance serves one account. To keep several clients’ sites apart, plan one instance per client.
- Each instance has its own cache. Two instances don’t share their copies of your pages.
- No global network. Your instances are where you install them, and nowhere else.
- No protection against network-level volumetric attacks. That stays with your hosting provider or network operator.
For teams that want to stay in control
Hosting providers and MSPs
Integrators and agencies
Regulated sectors
Internal infrastructure
If you look after several clients’ sites, our page on website security for agencies and hosts shows how to run them all from one console. And if you’re comparing it with the service in front of your site today, our feature-by-feature comparison sets out what you keep and what you lose.
Questions about running it yourself
Does the on-premise version do everything the managed service does?
Yes: it’s the same proxy, with the same protection, performance and analytics. One nuance: shared reputation, which is opt-in, travels between the sites on one console. With your own console, it only covers your sites.
What happens if the console can’t be reached?
Your sites keep being served and protected. The instance carries on with its last configuration and latest verdicts, sets its observations aside on disk and replays them without duplicates once the console responds. Taking the console down, for maintenance or after a failure, doesn’t affect your visitors.
Do I need to open a port for the console?
No. The instance opens the channel to the console, over HTTPS, using its token. You only open what serves your visitors.
How do updates work?
Install the new version of the package or image, then reload, without dropping requests in flight. The console and the instances move to each new version together.
How much does it cost?
On quotation. Tell us about your setup in your early access request, and we’ll come back with a proposal.
Put the same protection in front of your sites, without moving your infrastructure
Request early access, or talk to us about running it on your own servers. A new instance starts by observing, so you see your traffic before you set anything.