Coder Legion - Recent posts tagged selfhosted

Why I Protect Only Some Homelab Services With a WAF

Sat, 24 Oct 2026 02:25:33 +0000

A public hostname changes what a homelab service is. A notes app, a media index, or an admin panel that answers from outside the house is no longer a LAN convenience. It is a web application on the internet, and it can be probed for the same injection, traversal, and abuse patterns aimed at any other site. I place a self-hosted WAF in front of those services when, and only when, I can publish them as HTTP or HTTPS through a reverse proxy. I do not treat that choice as a blanket rule for every container on the network.

SafeLine is a self-hosted web application firewall meant to protect web apps by filtering and monitoring HTTP traffic between the application and the internet. Deployed in front of the app, it works as a reverse proxy: clients pass through it before they reach the server, and it blocks malicious HTTP and HTTPS traffic while forwarding what its policies treat as safe. The same description says it also aims to prevent unauthorized data from leaving the app. Those statements are the product model I rely on, and they come from the project documentation at https://docs.waf.chaitin.com/en/home.

The attack list is specific enough to use as a decision filter. The introduction names SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. Core capabilities listed alongside that coverage are defenses for web attacks, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Rate limiting throttles traffic above defined limits to defend against DoS attacks, brute-force attempts, traffic surges, and other abuse. A CAPTCHA challenge is documented as allowing human users while blocking crawlers and bots. An authentication challenge blocks visitors who do not enter the required password. Dynamic protection, when turned on, encrypts HTML and JS from the web server on each visit. I cite that feature set from https://docs.waf.chaitin.com/en/home rather than assuming extra homelab plugins.

That scope also tells me what not to expect. The configuration guide says SafeLine is developed on nginx and acts as an HTTP and HTTPS reverse proxy: it receives traffic for the original site, cleans malicious traffic, and forwards the rest to the upstream application, as described at https://docs.waf.chaitin.com/en/GetStarted/AddApplication. A database port or an SSH listener is not that kind of application. Putting a WAF hostname in front of them is not a documented protection path, so I leave them off this design.

Before I move a self-hosted service, I run a short go or no-go list.

The app must be reachable as a web origin. In the console, Add Application asks for a domain, hostname, or IP, a listen port such as 80 or 443, and an upstream address. HTTPS apps need the SSL option checked. After saving, the domain must resolve to the IP of the SafeLine server. If I cannot make that DNS change, I do not pretend the app is protected.

The host must meet the install floor in https://docs.waf.chaitin.com/en/GetStarted/Deploy. That guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support ssse3. I confirm those facts with the documented commands: uname -m, docker version, docker compose version, cat /proc/cpuinfo | grep "processor", free -h, df -h, and lscpu | grep ssse3. A homelab node that fails any line is not a candidate, even if the web app itself is small.

Architecture has a license constraint I do not skip. For ARM, the guide sets ARCH_SUFFIX to -arm and uses the ARM Postgres image. It also states that SafeLine on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. An ARM box can look ideal for a quiet homelab and still be the wrong edition.

Release choice is part of the same checklist. Setting RELEASE to -lts selects the LTS build, but the deploy guide says the LTS version will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and it strongly recommends upgrading to the latest version. I stay on the current release unless I have a concrete reason not to.

The recommended install is the automated English command from that same deploy page, and it needs root: bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en. Manual setup is also documented: create /data/safeline with at least 5 GB free, download the compose file, write .env, generate a 64-character hex detector management token, a 64-character hex management internal token, and a 16-character alphanumeric detector AES key, lock down permissions, then start with docker compose up -d. The console opens at https://<safeline-ip>:9443/. The initial administrator account comes from docker exec safeline-mgt resetadmin, and the printed username and password have to be saved then. The deploy page remains the source for SAFELINE_DIR, IMAGE_TAG, MGT_PORT, POSTGRES_PASSWORD, SUBNET_PREFIX, and the remaining variables.

Once the console is up, I add one application, point DNS at the SafeLine host, and test with the sample requests in the application guide: a SQL injection query string, an XSS payload, a path traversal payload, a code injection payload, and an XXE payload, with my domain in place of the example host. A blocking page means the request was stopped. I then open the attack list and click detail so the event is confirmed in the console, not only in the browser.

Published evaluation numbers are a policy warning, not a promise about my apps. On 33,669 samples, https://docs.waf.chaitin.com/en/home reports SafeLine Balance at 71.65 percent detection, 0.07 percent false positives, and 99.45 percent accuracy, and SafeLine Strict at 76.17 percent detection, 0.22 percent false positives, and 99.38 percent accuracy. Strict handling detects more and also raises the false-positive figure. After I enable stricter handling, I retest ordinary actions such as login and upload before I call the site done. The docs call the product production-ready; I still watch the first real clients.

I also keep the management plane boring. MGT_PORT defaults to 9443 in the sample environment, and MGT_PROXY is only for extra proxy layers in front of the console. It should stay at 0 unless I am actually configuring that proxy. If I retire the install, the documented path is to enter the SafeLine directory, run docker compose down, and remove that directory. Community support is Discord, including the #FAQ channel, plus GitHub issues, as noted at https://docs.waf.chaitin.com/en/home.

The decision is narrow. Use this WAF when a self-hosted web service must be reached from outside, when DNS can target the reverse proxy, and when the host matches the documented platform rules. Do not use it as a reason to publish services that should stay private, and do not describe it as an integration with a specific tunnel, panel, or orchestrator. The supported path is the one in the application guide: domain, port, upstream, and a domain that resolves to SafeLine.

Which self-hosted services should sit behind a WAF?

Only web apps you can publish as HTTP or HTTPS. SafeLine receives traffic for the original site, cleans malicious requests, and forwards the rest to the upstream, which is the model in https://docs.waf.chaitin.com/en/GetStarted/AddApplication. Non-web listeners are outside that guide.

Is a small homelab host enough?

The documented minimum is 1 CPU core, 1 GB of memory, and 5 GB of disk, on Linux with Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, and a CPU with ssse3, per https://docs.waf.chaitin.com/en/GetStarted/Deploy. ARM also requires a Pro license. The Personal Edition is not supported on ARM.

What do I enter for one public site?

Add an application with the domain, hostname, or IP, the listen port, and the upstream address. Check SSL for HTTPS. Resolve that domain to the SafeLine server IP, as described at https://docs.waf.chaitin.com/en/GetStarted/AddApplication. Rate limiting, CAPTCHA, authentication challenge, and dynamic HTML or JS encryption are separate controls from https://docs.waf.chaitin.com/en/home.

How can I verify that a probe was blocked?

Send the documented SQL injection, XSS, path traversal, code injection, and XXE examples to your own domain. A blocking page means the defense fired. Open the attack list and click detail to confirm the record.

No. It filters traffic for web apps you choose to expose. It does not patch the upstream or justify publishing a service that should remain private. If you remove the install, use docker compose down and delete the install directory, following https://docs.waf.chaitin.com/en/GetStarted/Deploy.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Choose a WAF for a Homelab Before You Publish Anything

Sat, 24 Oct 2026 02:25:01 +0000

A homelab rarely fails in one dramatic way. It fails when a useful web app is reachable, a password form is guessable, and nobody has decided which requests are allowed to touch the origin. A WAF can help, but only if you treat it as a reverse proxy with a defined job, not as a label you place on every container.

SafeLine is documented as a self-hosted WAF that protects web apps by filtering and monitoring HTTP traffic between a web application and the Internet. Deployed in front of an app, it is a reverse proxy: clients reach the WAF first, and the WAF forwards traffic it considers safe to the origin while blocking malicious HTTP and HTTPS requests and unauthorized data leaving the app. That model is the whole decision. If a self-hosted service is not an HTTP or HTTPS application you can place behind that proxy, this checklist should stop you from promising protection the product docs do not describe. Source: https://docs.waf.chaitin.com/en/home

Sort services before you sort controls

Write down every service you want to protect and mark only those that speak HTTP or HTTPS. A photo library, a notes site, a dashboard, or a small API can belong on the list when you can name a domain, hostname, or IP, a listen port, and an upstream address. A database port, a raw game server, or a protocol that never becomes an HTTP request does not become a WAF application just because it runs on the same host.

The official application flow is concrete. In the Web Admin Console, open Applications and choose Add Application. Enter the original app domain, hostname, or IP. Enter the port SafeLine will listen on, such as 80 or 443, and check the SSL option for HTTPS apps. Enter the upstream, which is the real address used to forward traffic. After that, resolve the name you entered to the IP of the server where SafeLine runs, then reach the protected app through that name. If you cannot complete those four facts, the service is not ready for this path. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Keep the origin from being a shortcut. The value of the proxy is that clients pass through it before they reach the server. If the same app is still published on a second port, a second hostname, or a direct LAN address that bypasses the WAF, the checklist is unfinished even if the console shows a healthy application.

Match documented threats to homelab exposure

The product documentation names a wide set of web attacks, including SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. Core capabilities listed alongside that coverage are web-attack defense, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Source: https://docs.waf.chaitin.com/en/home

For a homelab, translate those names into exposure, not into a feature tour. A form or query string that reaches a database-backed app is a reason to care about injection and path traversal. A login page on a name that resolves from outside the house is a reason to care about brute force. A site that suddenly attracts scripted clients is a reason to care about bots and floods. An app you only use over a trusted VPN may still deserve the proxy if the origin would be dangerous when that VPN rule is wrong, but the checklist should say so explicitly.

Do not invent a connector for a particular self-hosted brand. The supplied docs describe a generic reverse-proxy application. They do not document a special integration for any homelab suite. If an app needs a custom header, a long-lived connection, or an existing proxy in front of it, test that behavior yourself and treat anything beyond domain, port, upstream, and DNS as unverified.

Pick controls by failure mode

Blocking web attacks is the baseline. The feature list says SafeLine defends against web attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal. Rate limiting is separate. The docs describe it as a way to throttle traffic that exceeds defined limits, aimed at DoS attacks, brute-force attempts, traffic surges, and other abuse. A CAPTCHA challenge is for bot attacks: human users are allowed through, while crawlers and bots are blocked. An authentication challenge is a password gate: when it is on, visitors must enter the password or they are blocked. Dynamic protection is different again: when it is on, HTML and JS from the web server are dynamically encrypted on each visit. Source: https://docs.waf.chaitin.com/en/home

A practical homelab mapping looks like this. Use attack blocking for any app whose parameters, uploads, or paths are reachable. Add rate limiting where login, search, or API routes can be hammered. Consider CAPTCHA where anonymous bots, not forgotten passwords, are the problem. Use the authentication challenge only when a shared password gate is acceptable for every visitor of that application, because it will block people who do not have that password. Turn on dynamic protection when you specifically want HTML and JS encrypted per visit, and verify that your own pages still work. None of these toggles replaces patching the origin app.

Published evaluation numbers are a tuning warning, not a score you should paste onto your hardware. On 33669 samples, the docs report SafeLine Balance at 71.65 percent detection, 0.07 percent false positives, and 99.45 percent accuracy, and SafeLine Strict at 76.17 percent detection, 0.22 percent false positives, and 99.38 percent accuracy. Strict raises detection and also raises the false-positive rate compared with Balance. For a homelab, that means you should watch the attack list after you change policy, especially if household tools start failing on ordinary requests. Source: https://docs.waf.chaitin.com/en/home

Confirm the host can carry the proxy

The deploy guide states minimums: Linux; x86_64 or arm64; Docker 20.10.14 or above; Docker Compose 2.0.0 or above; 1 CPU core, 1 GB memory, and 5 GB disk; and a CPU with SSSE3. Documented checks include uname -m, docker version, docker compose version, processor count, free -h, df -h, and lscpu | grep ssse3. A small lab box can meet the minimum and still feel tight once logs, database data, and several proxied apps share that 1 GB. Plan disk beyond the 5 GB floor if you expect to keep attack history.

ARM needs an extra decision. The deploy guide says SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. An arm64 homelab board is therefore not the same choice as an x86_64 mini PC. If you are looking at the LTS channel, note that LTS is no longer maintained starting from 9.1.0-LTS (14 August 2025), and the docs strongly recommend upgrading to the latest version. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

The console itself is part of the exposure review. After install, the web console is https://<safeline-ip>:9443/. The initial admin account is retrieved with docker exec safeline-mgt resetadmin. Treat that management port as a privileged surface: it is how you add applications and read attack detail, so it should not be casually published beside the apps you are trying to protect.

Prove the path with the documented tests

After DNS points at the SafeLine host, use the official test cases with your own domain in place of the example host. The docs give SQL injection as /?id=1+and+1=2+union+select+1, XSS as /?id=<img+src=x+onerror=alert()>, path traversal as /?id=../../../../etc/passwd, code injection as /?id=phpinfo();system('id'), and an XXE-style query. A blocking page means the attack was defended. Then open the console attack list and click detail so you can see what was recorded, not only what the browser showed. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Repeat one normal visit after each test. A homelab WAF that blocks the sample attacks and also blocks your own bookmark is not finished. The docs state that SafeLine is production-ready, but that statement does not mean every policy is correct for your apps. Your proof is the proxy path, the block page, the attack detail, and a clean legitimate request.

Does a homelab WAF cover every self-hosted service?

No. The documented role is an HTTP and HTTPS reverse proxy in front of a web application. Services that you cannot describe with a domain, hostname, or IP, a listen port, and an upstream should stay outside this design until you have a real web path for them.

Which homelab host facts are actually required?

The deploy guide requires Linux on x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, at least 1 core, 1 GB of memory, 5 GB of disk, and SSSE3. ARM installs need a Pro license; the Personal Edition is not supported on ARM.

Should I enable every challenge on day one?

Not by default. Rate limiting targets excess traffic, brute force, surges, and abuse. CAPTCHA targets bots. The authentication challenge blocks visitors who do not enter its password. Dynamic protection encrypts HTML and JS on each visit. Enable the control that matches the failure you are seeing, then retest a normal session.

How do I know the WAF, not another hop, blocked the request?

Use the documented attack URLs against the name that resolves to the SafeLine server. A blocking page is the first sign. The console attack list and its detail view are the second. If the origin is still reachable on another address, fix that bypass before you trust the result.

What should I leave off this checklist?

Leave off claims the sources do not make: special integrations for named homelab apps, extra protocols, pricing, and any promise that a minimum lab host will behave like a large deployment. Also leave the management console unpublished to the same audience as the apps, and prefer a maintained release over the unmaintained LTS line if you are choosing a version now.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Open Source vs. Proprietary: Why We Built Parts of AnimeArray with Open-Source Tools

Sat, 17 Oct 2026 16:56:37 +0000

There's a question we get every time someone finds the site for the first time. It usually arrives about ten seconds after they realise AnimeArray is free:

"So who's paying for all this? What's the catch?"

It's a fair question, and for a while I didn't have a good answer beyond "advertising covers the hosting." That was true but it was the boring half of the story. The interesting half is why we built most of what runs the site ourselves, when we could have assembled the same product out of almost entirely commercial services and shipped it in a fraction of the time.

I've been chewing on that question for long enough that I figured the answer was worth writing down properly — including the parts where we made the wrong call.

What "owning it" actually got us

The first thing you get is the ability to read the code. Not documentation about it — the code.

This sounds obvious once you say it, but I only appreciated it properly during an incident a few months in. Something in the request-handling layer started throwing intermittently. Not consistently enough to be obvious, not rarely enough to ignore. I lost a couple of hours reading the source of the component that was misbehaving, found the logic error, and fixed it myself.

The alternative was a support ticket with a stack trace I didn't fully understand, waiting on a response from someone who would need my description of the problem to even start investigating. That's not a criticism of vendors — it's just a real difference in how long the problem takes to die. On a small project, an hour versus a week is the whole ballgame.

The second thing is exit cost, and this is the one I underweighted for a long time.

Every proprietary tool in a stack is a dependency you don't control. Pricing changes. Features get deprecated. APIs shift under you. The vendor pivots toward a different market. Individually these are survivable. Stacked across a dozen tools, they add up to something you can no longer actually move, even if every individual part is replaceable on paper.

The reason we care is specific: the expensive, hard-won parts of what we built — the recommendation logic that understands what you actually watched, the systems that keep twelve characters sounding like twelve different people — those live in our code, not inside somebody else's product. If we changed direction tomorrow, we'd carry that work with us. That was deliberate, even if I didn't have this vocabulary for it at the time.

The third is predictable cost, which sounds boring until you have to present a budget.

Open source tooling isn't free. It's labour and hardware, both of which you can see coming and forecast. What it avoids is per-seat licences and metered APIs that scale unpredictably and tend to punish you precisely when you start succeeding — which is a genuinely unpleasant property to own.

And the fourth is privacy, though I want to frame it carefully. It's not that open source is more private by some moral property. It's structural. When you run the software, the data stays where you put it. You don't need to publish a policy about what you won't collect, because there's no third party standing in the path to collect it.

The part nobody wants to hear

Open source is not free, and "we built it ourselves" is not a synonym for "we did nothing for it."

Some of the most valuable software in our stack was donated by someone, and I'm grateful for it every day. But the hours we spent configuring, debugging, updating, monitoring and repairing it are absolutely real, and they come out of the same revenue that has to cover hosting and bandwidth. On a small team that's the largest cost we carry, and it's invisible if you only look at the licensing line and conclude we're saving money.

We own the maintenance. Every dependency is something we chose to run, which means somebody is responsible for watching it, updating it, and dealing with the moment an upstream release breaks something we rely on. A company selling commercial software does that work as part of the price. We do it as part of the job. If you're building something small and reading this thinking it's a free shortcut, that's the misunderstanding I most want to correct.

There's a version of this that only works at a certain ratio. If our traffic grew a hundredfold, we'd need to make completely different calls — probably more managed services, more outsourced operations, and a much smaller independent stack. We don't pretend the current approach scales forever. We think it's honest about what it costs and right for where we are today, and those are different questions.

Where we deliberately chose proprietary

I'm not going to pretend open source wins every round, because it doesn't, and an article that only celebrates its own decisions is an advertisement.

We use paid tools in a few categories, and I'd make the same call again:

Things where a support contract is worth more than the licence. When a problem has a clear escalation path and a known owner, it gets solved faster than anything we could diagnose ourselves. That's not a bad thing to buy.

Services with no credible open equivalent at the quality level we need. Rebuilding a search index or a video pipeline in order to avoid a subscription isn't virtue, it's waste. Not everything important is a matter of principle.

Anything where our own time is the scarcest resource and licensing it is genuinely cheaper than building it. This one is easy to get wrong because founders tend to over-value building. Sometimes building is the right call and it's satisfying. Sometimes it's ego with a maintenance bill attached.

The other thing worth saying: we don't treat open source as a purity test. A permissive licence is legal permission, not a guarantee of quality, security, or maintenance. Popularity on a package registry tells you how many people use something. It does not tell you whether anybody is looking after it.

The four questions we ask

When a new tool comes up, we run it through a checklist. It's short on purpose, because a long checklist doesn't get used.

Can we read it? If we can't inspect what we're running, we can't honestly reason about whether it belongs anywhere near a stack that handles user accounts. This is a threshold question — a tool that fails it usually doesn't get a second conversation, regardless of price.
What's the exit? If this vanished tomorrow, how long would it take to replace it? High exit cost on something load-bearing is a decision we make deliberately, or not at all.
Who pays when it breaks? If the honest answer is "we do" and we're not in a position to staff that, we shouldn't choose it. No amount of being right about the long term compensates for a small team quietly becoming the on-call rotation.
Does it compound? Does owning this make the next thing easier to build, or does it create a brand new category of problem? Tools that make later work faster are worth more than tools that are marginally better today.

The real output of this isn't a score. It's that it forces us to be honest about which category a decision falls into, which is where most bad choices actually get made — in the gap between "it's free" and "we can maintain it."

What this actually means for the people who use the site

This isn't infrastructure trivia. It shows up in things people notice.

Because we own the software, we can promise the things that matter and keep them. Everything stays free and usable without an account, because there's no per-user cost to pass on — you can try AnimeArray for as long as you like and never be asked for a card.

It also means we can be straight about what the site is and isn't. It's an independent fan project. It hosts no video. It isn't affiliated with, endorsed by, or connected to any studio, publisher, or licensor. There's no commercial arrangement making any of that awkward to say, and I'd rather be boringly accurate than vaguely impressive.

And it means we can fix things without asking anyone's permission. When something wasn't working well — and things have, repeatedly — we changed it. Nobody had to approve a roadmap.

If you want to see how this reads in practice, the character chats are the part I'm proudest of, mostly because keeping twelve distinct voices distinct is much harder than it sounds and much more satisfying than I expected. The Otaku AI assistant is the other one, and it exists because we kept wanting a thing that didn't exist.

If you're starting something similar

The question isn't open source versus proprietary. Anyone who frames it that way has already decided and is looking for permission.

The question is: do you want to own your dependencies, and are you prepared to pay for that honestly?

If yes, the tooling is the easy part. You'll find the shape of your stack follows fairly quickly from there.

If no — and that's a completely legitimate answer for many projects — you should lean toward managed services, accept the lock-in consciously, and spend the time you saved on the part of the product that only you can build.

The mistake I'd avoid is picking one and then resenting it later. Either position is defensible. Being unable to afford the one you chose is not.

AnimeArray is at animearray.site if you want to see what the outcome looks like. It's free, it needs no account, and every decision I described above is visible in the finished product — including the compromises.

Reverse Proxy or Transparent WAF? A Checklist for Web Teams

Fri, 16 Oct 2026 07:56:12 +0000

Reverse Proxy or Transparent WAF? A Checklist for Web Teams

Ask five questions before deployment: Can the origin be restricted? Who terminates TLS? Where are logs collected? How will bypasses be detected? What is the rollback path?

A reverse-proxy WAF makes these decisions explicit in the HTTP path. A transparent design may reduce topology changes but can require more network-level coordination. SafeLine’s documented deployment model is a self-hosted reverse proxy, so use the official guide to validate fit.

FAQ

Does SafeLine support both rule-based and semantic protection?

SafeLine documents layered application protection and dynamic protection features. Check the current product documentation for the exact behavior of each release.

Should I test changes before production?

Yes. Use a staged rollout, review logs, and verify legitimate requests before tightening policies.

Where can I check current Pro pricing?

Use the official 700K+ Installs Sale page for current campaign terms.

Is the sale renewable at the same price?

The campaign page says promotional pricing ends with the campaign; renewals return to regular pricing.

What evidence would you use to compare protection modes in your own traffic?

Read the full guide on dev.to:

📖 Reverse Proxy or Transparent WAF? A Checklist for Web Teams

SafeLine Pro 700K+ Installs Sale

Reverse Proxy or Transparent WAF? A Checklist for Web Teams

Fri, 16 Oct 2026 06:23:12 +0000

Reverse Proxy or Transparent WAF? A Checklist for Web Teams

Ask five questions before deployment: Can the origin be restricted? Who terminates TLS? Where are logs collected? How will bypasses be detected? What is the rollback path?

FAQ

Does SafeLine support both rule-based and semantic protection?

SafeLine documents layered application protection and dynamic protection features. Check the current product documentation for the exact behavior of each release.

Should I test changes before production?

Yes. Use a staged rollout, review logs, and verify legitimate requests before tightening policies.

Where can I check current Pro pricing?

Use the official 700K+ Installs Sale page for current campaign terms.

Is the sale renewable at the same price?

The campaign page says promotional pricing ends with the campaign; renewals return to regular pricing.

What evidence would you use to compare protection modes in your own traffic?

Read the full guide on dev.to:

📖 Reverse Proxy or Transparent WAF? A Checklist for Web Teams

SafeLine Pro 700K+ Installs Sale

Reverse Proxy WAF vs Transparent Bridge: A Deployment Decision

Fri, 16 Oct 2026 06:22:39 +0000

Reverse Proxy WAF vs Transparent Bridge: A Deployment Decision

The main difference is how clearly the WAF participates in the application traffic path. A reverse proxy is an explicit HTTP gateway. A transparent bridge is designed to minimize visible topology changes.

Reverse proxy trade-offs

The explicit hop can make routing and policy ownership easier to reason about. It also means the team must plan certificates, upstream connectivity, health checks, and origin restrictions.

Transparent designs

A transparent design may fit networks where changing endpoints is difficult, but it can make troubleshooting and application context more dependent on the surrounding network.

SafeLine documents the reverse-proxy model, application onboarding, and web attack protections. Compare that documented model with your existing topology before choosing a deployment.

FAQ

Does SafeLine support both rule-based and semantic protection?

SafeLine documents layered application protection and dynamic protection features. Check the current product documentation for the exact behavior of each release.

Should I test changes before production?

Yes. Use a staged rollout, review logs, and verify legitimate requests before tightening policies.

Where can I check current Pro pricing?

Use the official 700K+ Installs Sale page for current campaign terms.

Is the sale renewable at the same price?

The campaign page says promotional pricing ends with the campaign; renewals return to regular pricing.

What evidence would you use to compare protection modes in your own traffic?

Read the full guide on dev.to:

📖 Reverse Proxy WAF vs Transparent Bridge: A Deployment Decision

SafeLine Pro 700K+ Installs Sale

SafeLine’s 700K Install Sale Is Live: Save up to 35% on Pro

Mon, 12 Oct 2026 10:48:13 +0000

SafeLine’s 700K Install Sale Is Live: Save up to 35% on Pro

SafeLine has passed 700,000 installs. To celebrate, SafeLine Pro is up to 35% off through November 30, 2026.

[Image suggestion: SafeLine 700K milestone campaign banner]

SafeLine is a self-hosted web application firewall (WAF). It helps detect common attacks like SQL injection and cross-site scripting (XSS) before they reach your applications. It also includes CC protection and human verification, with one-click deployment and a graphical interface for day-to-day management.

[Image suggestion: SafeLine product dashboard]

What Pro adds

As your website grows, you may need more visibility, flexible rules, or support for more applications. Pro includes:

Attack overview: see traffic and attack activity in visual reports.
Unlimited applications: add more sites as you grow.
Enhanced rules: use layered protection and flexible Allow/Deny controls.
Performance and high availability: enable maximum-performance mode and sync configuration across master–slave nodes.

[Image suggestion: Pro attack overview or feature comparison]

Sale plans

The sale runs October 12–November 30, 2026.

Plan	Regular price	Sale price	Discount
1-Year Pro	$1,000	$880	12% off
2-Year Pro	$2,000	$1,580	21% off
3-Year Pro	$3,000	$2,250	25% off
5 × 1-Year Pro	$5,000	$3,500	30% off
10 × 1-Year Pro	$10,000	$6,500	35% off

[Image suggestion: Pricing cards showing all five sale plans]

The 2-Year plan works out to $790 per year. The 3-Year plan works out to $750 per year. These are one-time payments for the full license term, not annual installments.

Multi-year plans extend one license. Multi-license packs include separate one-year licenses. All discounted licenses in a purchase must be placed in one order. Discounts generally can’t be combined with other offers or codes.

Before you buy

Monthly Pro and Lite aren’t part of this sale.
There’s no purchase limit on discounted packs.
Renewals after the campaign return to regular pricing.
Check the campaign page for full terms and license details.

[Image suggestion: Short purchase steps or checkout screenshot]

Ready to choose a plan? Visit the SafeLine campaign page. You can also try the online demo or view SafeLine on GitHub.

The SafeLine Pro 700K install sale ends November 30. Save up to 35%.

Prices and terms are based on the English-language campaign page. Regional offers may differ.

SafeLine’s 700K Install Sale Is Live: Save up to 35% on Pro

Mon, 12 Oct 2026 10:44:13 +0000

SafeLine has passed 700,000 installs. To celebrate, SafeLine Pro is up to 35% off through November 30, 2026.

What Pro adds

As your website grows, you may need more visibility, flexible rules, or support for more applications. Pro includes:

Attack overview: see traffic and attack activity in visual reports.
Unlimited applications: add more sites as you grow.
Enhanced rules: use layered protection and flexible Allow/Deny controls.
Performance and high availability: enable maximum-performance mode and sync configuration across master–slave nodes.

[Image suggestion: Pro attack overview or feature comparison]

Sale plans

The sale runs October 12–November 30, 2026.

Plan	Regular price	Sale price	Discount
1-Year Pro	$1,000	$880	12% off
2-Year Pro	$2,000	$1,580	21% off
3-Year Pro	$3,000	$2,250	25% off
5 × 1-Year Pro	$5,000	$3,500	30% off
10 × 1-Year Pro	$10,000	$6,500	35% off

[Image suggestion: Pricing cards showing all five sale plans]

The 2-Year plan works out to $790 per year. The 3-Year plan works out to $750 per year. These are one-time payments for the full license term, not annual installments.

Before you buy

Monthly Pro and Lite aren’t part of this sale.
There’s no purchase limit on discounted packs.
Renewals after the campaign return to regular pricing.
Check the campaign page for full terms and license details.

[Image suggestion: Short purchase steps or checkout screenshot]

Ready to choose a plan? Visit the SafeLine campaign page. You can also try the online demo or view SafeLine on GitHub.

The SafeLine Pro 700K install sale ends November 30. Save up to 35%.

Prices and terms are based on the English-language campaign page. Regional offers may differ.

Cloud WAF or Self-Hosted WAF? Four Questions for Teams

Mon, 12 Oct 2026 06:45:09 +0000

Cloud WAF or Self-Hosted WAF? Four Questions for Teams

A short checklist can make the choice concrete. Where must traffic be processed? Who owns the WAF? How will you test policy changes? What is the recovery plan if the enforcement point fails?

Traffic and data path

Document whether requests may pass through an external edge and whether origin services can be reached only through the WAF. These answers often narrow the options quickly.

Ownership and rollout

Cloud services reduce some infrastructure ownership. Self-hosted services place more responsibility with your team but can provide direct control of deployment and policy. Either model needs staged rollout, logs, and a way to restore service.

SafeLine operates as a reverse proxy in front of the web application and documents protections including web attack defense, rate limiting, CAPTCHA, authentication challenges, and dynamic protection.

What SafeLine adds

SafeLine is documented as a self-hosted WAF that works as a reverse proxy in front of a web application. Its official documentation lists defenses for SQL injection, XSS, code injection, SSRF, path traversal, brute force, HTTP flood, and bot abuse. It also documents rate limiting, CAPTCHA challenges, authentication challenges, and dynamic protection.

The right deployment still depends on your traffic path, application behavior, and operational capacity. Start with one application, confirm the proxy path, review logs, and tune policies before expanding coverage.

FAQ

Does a WAF replace every other security control?

No. It focuses on web traffic and should complement network controls, secure code, identity controls, patching, and monitoring.

Is reverse proxy placement important?

Yes. Requests need to pass through the WAF before reaching the protected application.

Should I enable every protection immediately?

Begin with a monitored rollout and validate legitimate requests before tightening policies.

Where can I verify the product details?

Use the official SafeLine documentation and its deployment guides.

What part of your current traffic path would you measure first before changing the security layer?

Read the full guide with screenshots on dev.to:

📖 Cloud WAF or Self-Hosted WAF? Four Questions for Teams

⭐ SafeLine WAF on GitHub

Cloud WAF vs Self-Hosted WAF: A Deployment Decision Guide

Mon, 12 Oct 2026 06:44:38 +0000

Cloud WAF vs Self-Hosted WAF: A Deployment Decision Guide

The cloud versus self-hosted decision is an operations decision as much as a feature comparison. Ask who owns the traffic path, who maintains the enforcement point, and who responds when protection affects legitimate users.

Cloud advantages

A managed service can reduce installation and maintenance work. It may be a good fit when your team wants a provider to handle much of the edge infrastructure and can route traffic through that service.

Self-hosted advantages

A self-hosted WAF can fit environments where the team wants local control of routing and policy. It can also be easier to align with an existing reverse-proxy and private infrastructure design, provided the team operates it reliably.

SafeLine documents installation, reverse-proxy behavior, application onboarding, rate limiting, and challenge features. Use those official guides to evaluate the work against your own topology.

What SafeLine adds

FAQ

Does a WAF replace every other security control?

No. It focuses on web traffic and should complement network controls, secure code, identity controls, patching, and monitoring.

Is reverse proxy placement important?

Yes. Requests need to pass through the WAF before reaching the protected application.

Should I enable every protection immediately?

Begin with a monitored rollout and validate legitimate requests before tightening policies.

Where can I verify the product details?

Use the official SafeLine documentation and its deployment guides.

What part of your current traffic path would you measure first before changing the security layer?

Read the full guide with screenshots on dev.to:

📖 Cloud WAF vs Self-Hosted WAF: A Deployment Decision Guide

⭐ SafeLine WAF on GitHub

SafeLine WAF vs Imperva: Self-Hosted WAF vs Enterprise Cloud Protection

Sat, 10 Oct 2026 20:30:41 +0000

SafeLine WAF vs Imperva: Self-Hosted WAF vs Enterprise Cloud Protection

When people compare SafeLine to Imperva, they're usually comparing two very different things: a lightweight self-hosted WAF and a full enterprise cloud security stack. Here's how to think about which one fits your situation.

What each one is

SafeLine WAF is a self-hosted web application firewall by Chaitin. Install it on your own server with one command, and it runs as a reverse proxy that inspects every HTTP request using a semantic engine — blocking SQL injection, XSS, and bots without signature upkeep. The Community Edition is free (10 apps, 800 QPS).

Imperva is an enterprise cloud WAF and application-security platform. It sits in front of your apps at the network edge, bundling a WAF with a CDN, DDoS protection, and bot management. It's geared toward larger organizations with compliance and SLA requirements.

The difference that matters: the model

SafeLine is self-hosted. You run it, you own the data, you pay nothing on the free tier. Best for teams that want control and predictable cost.
Imperva is a managed cloud service. You route traffic through Imperva's edge; they operate the infrastructure. Best for organizations that need an SLA, vendor support, and a broad security bundle.

Side by side

	SafeLine WAF	Imperva
Deployment	Self-hosted reverse proxy	Cloud edge (WAF + CDN)
Detection	Semantic analysis, no signature upkeep	Signature, behavior, and reputation at scale
Best for	Small teams, self-hosters, side projects	Enterprises with compliance and SLA needs
Data residency	On your server	Through Imperva's cloud
Cost	Free Community Edition; paid tiers	Enterprise subscription

Which should you pick?

If you run a handful of sites and want strong protection without a sales call or a monthly bill, start with a self-hosted WAF:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Open https://<your-server-ip>:9443, point it at your app, and you're done.

If you're at an organization with strict compliance, a required SLA, and a need for bundled CDN and bot management across many properties, a managed platform like Imperva is the more natural fit — at enterprise pricing.

FAQ

Is SafeLine "enterprise-grade"?

SafeLine's detection is production-grade: semantic analysis with low false positives, running at scale for many users. The free tier is sized for around 10 apps; larger needs use paid tiers.

Does Imperva require its CDN?

Imperva bundles a CDN, but you can use the WAF independently. A self-hosted WAF like SafeLine pairs with whatever CDN you already use.

Which is easier to start?

SafeLine: one install command, no account, no DNS change. Imperva: onboarding, routing setup, and a contract.

Can I self-host and still meet compliance?

Many teams run SafeLine in their own compliant environment and keep full control of logs and data residency — which is exactly why some organizations prefer self-hosted.

Ready to give SafeLine a try?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

What Is a WAF and How Does It Work? A Plain-English Guide

Sat, 10 Oct 2026 20:30:37 +0000

What Is a WAF and How Does It Work? A Plain-English Guide

If you run a website, you've probably been told to "put a WAF in front of it." Here's what that actually means — no jargon.

What "WAF" stands for

A Web Application Firewall protects your app at layer 7 (the application layer) — the part that speaks HTTP. Unlike a network firewall that only cares about IPs and ports, a WAF reads the content of requests and decides whether they're safe.

What problem it solves

Most web attacks arrive as ordinary-looking HTTP requests that carry malicious payloads: a login field stuffed with SQL, a URL containing a script tag, a flood of requests from a botnet. A WAF inspects those requests before they reach your application code and blocks the bad ones.

How it works

It sits in front of your app as a reverse proxy. Every request hits the WAF first.
It inspects the request — headers, URL, body, and cookies.
It decides allow / block / challenge based on its detection logic.
Clean traffic passes through to your app; everything else is stopped.

Two ways WAFs detect attacks

Signature-based: matches known attack patterns (like an antivirus). Needs constant updating, and novel attacks slip through.
Semantic analysis: understands what a request is trying to do (for example, "this is a SQL command"), so it catches variants without a signature. SafeLine uses this approach, which keeps false positives low.

Where it sits

A self-hosted WAF like SafeLine runs on your own server as a reverse proxy. You install it with one command:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Then open https://<your-server-ip>:9443, point it at your app, and it filters traffic. No third party in the path, no DNS change.

WAF vs firewall vs IPS

Network firewall: controls who can connect (IPs and ports).
IPS: blocks known network intrusions.
WAF: understands HTTP and blocks application-layer attacks. They're complementary, not interchangeable.

FAQ

Do I need a WAF if I use a CDN?

Many CDNs include a basic WAF, but a dedicated WAF gives finer control over application-layer rules. SafeLine focuses purely on that layer.

Will a WAF slow my site down?

A well-tuned WAF adds minimal latency. SafeLine's free tier handles 800 QPS per instance.

Is a WAF enough on its own?

It covers the application layer. Pair it with good patching, rate limiting, and (if needed) a CDN for fuller coverage.

Can I self-host a WAF for free?

Yes. SafeLine's Community Edition is free for up to 10 apps at 800 QPS and runs on a server you already have.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

SafeLine or CrowdSec? A Decision Guide for Your Stack

Fri, 09 Oct 2026 07:54:15 +0000

SafeLine or CrowdSec? A Decision Guide for Your Stack

People often ask "which one should I install?" as if SafeLine and CrowdSec are interchangeable. They're not — they protect different layers, so the real question is which layer is exposed first. Here's a quick way to decide what to deploy, and in what order.

Start with what's actually exposed

You run a public web app. Put SafeLine in front of it first. Its job is to inspect HTTP requests and block injection, XSS, and bots at the application layer — exactly the traffic your app receives.
You run a bare server with SSH and other services. Start with CrowdSec. It watches behavior across the host and bans malicious IPs (scanners, brute-forcers) at the firewall, before they reach anything.
Both describe you. Run both. SafeLine filters the app; CrowdSec guards the host. Order doesn't matter much.

A simple decision tree

Is a web app reachable from the internet? → SafeLine in front of it.
Does the server expose SSH or other login services? → CrowdSec to ban bad IPs.
Both? → Deploy both; they don't conflict.

What each one needs to run

SafeLine runs as a reverse proxy. One install command, point your app's traffic through the console, done. Free Community Edition covers up to 10 apps at 800 QPS.
CrowdSec runs as an agent plus a "bouncer" that enforces bans in your firewall (iptables/nftables). Add the collections for the services you actually run.

The mistake: picking the "more powerful" one

A common trap is choosing based on feature count and skipping the other. But a WAF that filters requests can't ban an SSH brute-forcer, and an IP-banning engine can't read a SQL injection payload. Choosing one and skipping the other simply leaves a layer open. The decision isn't SafeLine vs CrowdSec — it's which layer first, and usually the answer is both.

If you only do one today

Web app is your main risk → SafeLine.
Host/SSH brute force is your main risk → CrowdSec.

Then add the second when you have a moment. Incremental is fine; leaving a layer permanently open is not.

Don't ask which tool wins. Ask which layer is exposed — and cover it.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

From SSH Brute Force to SQL Injection: How SafeLine and Fail2ban Split the Work

Fri, 09 Oct 2026 07:08:41 +0000

From SSH Brute Force to SQL Injection: How SafeLine and Fail2ban Split the Work

Most server compromises start with one of two things: someone guessing a password, or someone slipping a malicious payload into a web request. Those two attacks live on completely different layers — which is exactly why Fail2ban and SafeLine aren't competitors. Walk through both attack paths and it becomes obvious where each tool belongs.

Attack path 1: SSH brute force

What happens: a bot hammers your SSH port with thousands of password attempts.

Who stops it: Fail2ban reads your authentication logs, counts the failures, and bans the offending IP by pushing a rule into your firewall (iptables, nftables, or firewalld).

Why SafeLine isn't in the loop: SafeLine sits in front of your web app, inspecting HTTP traffic. SSH isn't HTTP, so it never sees the attempt. That's not a limitation — it's scope. Fail2ban owns the host; SafeLine owns the app.

What happens: a crafted POST hits /login carrying a malicious payload designed to manipulate your database query.

Who stops it: SafeLine reads the request, and its semantic detection engine recognizes the injection attempt for what it is — regardless of the IP's reputation — and drops the request before it reaches your code.

Why Fail2ban struggles here: it sees an IP making a POST that returned a 200, which looks perfectly normal in a log. It has no visibility into the payload, so it can't tell a legitimate login from a malicious one.

The split, stated plainly

	Fail2ban	SafeLine
Sees	IPs and log patterns	The actual HTTP request
Stops	Brute force, scanners, repeat offenders	Injection, XSS, malicious bots
Layer	Host / network (L3–L4)	Application (L7)
Acts by	Banning the IP at the firewall	Dropping the bad request

Same server, two doors. Fail2ban locks the side door (SSH and service brute force); SafeLine locks the front door (your web app).

A sane setup order

Expose only what you must. Close unused ports; that alone shrinks your attack surface.
Fail2ban on the host. Protect SSH and any other services with login attempts. Tune the filters to your logs.
SafeLine in front of the web app. Install it as a reverse proxy and point your app's traffic through it:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Your app keeps running exactly as before — it's just now shielded by a filter that understands what a request is trying to do.

FAQ

Can one tool replace the other?

No. Fail2ban can't inspect request payloads; SafeLine doesn't ban IPs at the host level. They cover different layers.

Does SafeLine protect SSH?

No — and it's not meant to. SSH is handled by host-level tools like Fail2ban. SafeLine focuses on your web traffic.

Is Fail2ban open source?

Yes, Fail2ban is open-source and widely used for host intrusion prevention. SafeLine is a self-hosted WAF with a free Community Edition (up to 10 apps at 800 QPS).

If I only pick one, which?

If your risk is a public web app, start with SafeLine — that's where application attacks land. If your risk is SSH or service brute force, start with Fail2ban. Most servers end up with both.

Different attacks, different layers, different tools — used together, they close both doors.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

SafeLine WAF vs Fail2ban: App-Layer vs Host-Level Defense

Fri, 09 Oct 2026 06:34:40 +0000

SafeLine WAF vs Fail2ban: App-Layer vs Host-Level Defense

Fail2ban is one of the first tools people reach for when a server goes live — and for good reason. But it solves a different problem than a WAF. If you're wondering whether SafeLine replaces Fail2ban (or vice versa), the short answer is: they guard different layers, and you'll likely want both. Here's the breakdown.

What each one does

Fail2ban is an open-source intrusion-prevention tool. It watches your log files — SSH, web server, mail, whatever you point it at — and when an IP shows malicious behavior (repeated failed logins, bursts of 404s, obvious scans), it bans that IP by injecting a rule into your firewall (iptables, nftables, or firewalld). It's filter-and-ban, driven by regular expressions you configure.

SafeLine is a self-hosted WAF by Chaitin. It sits as a reverse proxy in front of your web app and inspects the content of every HTTP request, blocking SQL injection, XSS, and malicious bots using a semantic detection engine — it understands what a request is trying to do, rather than matching attack signatures.

The key difference: what gets inspected

Fail2ban acts on IPs, based on log patterns. It sees "this IP failed SSH 10 times" or "this IP requested /wp-admin 50 times" and blocks the IP. It never looks at the body of a legitimate-looking HTTP request.
SafeLine acts on requests, at layer 7. It reads the actual request your app receives and blocks the malicious ones — even from an IP that's never been seen before and has a clean reputation.

That's the crux: Fail2ban is great at stopping who is attacking (bad IPs, brute force), while SafeLine is great at stopping what the attack is (malicious payloads in the request).

A side-by-side look

	SafeLine WAF	Fail2ban
Primary job	Block web app attacks in HTTP requests	Ban IPs showing malicious log patterns
What it sees	Request content (SQLi, XSS, bot traffic)	Log lines (failed logins, scans)
Enforcement	Reverse proxy, drops bad requests	Firewall rule banning the IP
Detection style	Semantic analysis (no signature upkeep)	Regex filters you define
Covers	Application layer (L7)	Host / network layer (L3–L4)
Dashboard	Visual traffic & attack stats	Config files + CLI; no GUI

Can you run both?

Absolutely, and it's a common pairing:

Fail2ban protects the host. It locks down SSH brute-force and bans IPs hammering your services — the stuff that shows up in logs.
SafeLine protects the app. It filters the HTTP traffic that actually reaches your web service, catching injection and XSS that Fail2ban's log rules would never see.

Neither makes the other unnecessary. Fail2ban won't stop a SQL injection hidden in a valid-looking POST; SafeLine won't ban an IP brute-forcing your SSH port.

Which should you start with?

If your concern is a public web app, start with SafeLine — that's where application attacks land. Its free Community Edition covers up to 10 apps at 800 QPS and installs in one command:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Point it at your app via the console at https://<your-server-ip>:9443 and your requests are filtered. Then layer in Fail2ban for host-level brute-force protection if your server exposes SSH or other services.

FAQ

Does SafeLine replace Fail2ban?

Not entirely. SafeLine covers application-layer attacks; Fail2ban covers host-level IP banning (SSH brute force, etc.). They handle different layers.

Can Fail2ban stop SQL injection?

Only indirectly and poorly — it can ban an IP that triggers certain log patterns, but it can't inspect request payloads the way a WAF does. A WAF is the right tool for injection.

Is Fail2ban hard to maintain?

It's config-file driven: you write or tune filters (regex) for the services you watch. It's lightweight but less visual than a dashboard-based WAF.

Does SafeLine have a dashboard?

Yes. SafeLine's console shows traffic, blocked requests, and attack breakdowns without you parsing logs by hand.

Host-level banning and app-level filtering aren't competitors — together they close both doors.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

SafeLine WAF vs CrowdSec: WAF vs Behavior-Based Protection

Fri, 09 Oct 2026 06:31:48 +0000

SafeLine WAF vs CrowdSec: WAF vs Behavior-Based Protection

If you're hardening a server, you'll run into both SafeLine and CrowdSec — and it's easy to assume they're rivals. They're not, really. They protect different layers, and most teams that take security seriously run both. Here's where each one fits so you can decide what you actually need.

What each one does

SafeLine is a self-hosted web application firewall (WAF) by Chaitin. It sits in reverse-proxy mode in front of your web app and inspects every HTTP request — blocking SQL injection, cross-site scripting (XSS), and malicious bots before the traffic reaches your code. Its detection engine is semantic: instead of matching attack signatures, it analyzes what a request is trying to do, which keeps false positives low.

CrowdSec is an open-source, community-powered security engine. Its agents observe behavior across your hosts and share signals of malicious IPs with a global threat-intelligence network. When an IP shows bad behavior — scanning, brute-forcing, weird traffic patterns — CrowdSec bans it, usually by pushing rules into your firewall (iptables, nftables) or a upstream filter.

The key difference: layer

SafeLine works at layer 7 (the application layer). It reads the content of HTTP requests. A request that looks harmless to a firewall but carries a SQLi payload gets caught by SafeLine.
CrowdSec works at the network/host layer, based on behavior and IP reputation. It decides whether an IP is trustworthy and bans the ones that aren't. It doesn't deeply parse your application's request bodies.

Think of it this way: CrowdSec asks "is this IP a known bad actor?" and SafeLine asks "is this specific request malicious?" Both questions matter.

A side-by-side look

	SafeLine WAF	CrowdSec
Primary job	Block web app attacks (SQLi, XSS, bots)	Ban malicious IPs by behavior + reputation
Where it sits	Reverse proxy, in front of your app	Host agent + firewall/remediation bouncer
What it inspects	HTTP request content (L7)	IP behavior, log signals, community intel
Detection style	Semantic analysis (no signature upkeep)	Behavior rules + crowd-sourced intelligence
Dashboard	Visual traffic & attack stats	CLI + optional console; firewall rules
Cost	Free Community Edition (10 apps, 800 QPS)	Free / open-source

Can you run both?

Yes — and they complement each other well:

CrowdSec pre-empts. A known-bad IP trying to probe your site gets banned at the perimeter before it wastes your resources.
SafeLine catches what slips through. The request that does reach your app, carrying a clever payload, is stopped at the application layer.

Many self-hosted setups put CrowdSec on the host (to protect SSH and ban scanners) and SafeLine in front of the web app (to filter application attacks). Neither makes the other redundant.

Which should you start with?

If you run a public web app, start with a WAF — that's the layer attackers actually hit. SafeLine's free Community Edition covers up to 10 apps at 800 QPS and installs in one command:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Then open the console at https://<your-server-ip>:9443, point it at your app, and your traffic is filtered. Add CrowdSec afterward if you also want behavior-based IP banning across the host.

FAQ

Is CrowdSec a WAF?

No. It's an intrusion-prevention / IP-reputation engine. It bans bad IPs based on behavior and community intelligence but doesn't do deep HTTP payload inspection the way a WAF does.

Does SafeLine replace my firewall?

No. SafeLine filters application-layer traffic; your firewall still governs network access. They handle different layers.

Which has lower false positives?

SafeLine's semantic engine is built to minimize false positives on legitimate traffic. CrowdSec's behavior rules can occasionally flag aggressive-but-legitimate crawlers, which you tune via its allowlists.

Can SafeLine run on the same server as CrowdSec?

Yes. SafeLine runs as a containerized reverse proxy; CrowdSec runs as a host agent. They don't conflict.

Two layers, one goal: keep your app reachable to real users and invisible to attackers.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

SafeLine Reaches 700K Installs. A Pro Sale Is Coming.

Thu, 08 Oct 2026 10:13:56 +0000

SafeLine Reaches 700K Installs. A Pro Sale Is Coming.

Thanks for being part of the SafeLine community. To celebrate 700,000+ installs, a limited-time SafeLine Pro sale starts October 12.

Running a website takes time. You ship updates, help customers, and keep services online. All the while, your site keeps getting requests—some welcome, some not.

SafeLine helps protect websites from common attacks like SQL injection and cross-site scripting (XSS). It’s self-hosted and designed to be straightforward to deploy and manage.

When is Pro worth a look?

As your site grows, you may want more ways to understand traffic, tune protection, and manage more applications. SafeLine Pro adds:

An attack overview with visual traffic and attack data
Unlimited applications
Enhanced rules and more flexible Allow/Deny controls
Maximum-performance mode and configuration sync for high availability

The sale starts October 12

From October 12 to November 30, 2026, save up to 35% on selected annual Pro plans and multi-license packs. We’ll share the full prices and purchase details when the sale opens.

If you’re considering Pro, take a look at your current setup and think about what you’ll need next. Already using Pro? Check your license term and plan ahead.

SafeLine Pro sale: October 12–November 30. Save up to 35%.

Learn more about SafeLine · Try the online demo · View SafeLine on GitHub

Dates and terms follow the English-language campaign page. Regional offers may differ.

SafeLine Reaches 700K Installs. A Pro Sale Is Coming.

Thu, 08 Oct 2026 09:37:07 +0000

SafeLine Reaches 700K Installs. A Pro Sale Is Coming.

Thanks for being part of the SafeLine community. To celebrate 700,000+ installs, a limited-time SafeLine Pro sale starts October 12.

Running a website takes time. You ship updates, help customers, and keep services online. All the while, your site keeps getting requests—some welcome, some not.

SafeLine helps protect websites from common attacks like SQL injection and cross-site scripting (XSS). It’s self-hosted and designed to be straightforward to deploy and manage.

When is Pro worth a look?

As your site grows, you may want more ways to understand traffic, tune protection, and manage more applications. SafeLine Pro adds:

An attack overview with visual traffic and attack data
Unlimited applications
Enhanced rules and more flexible Allow/Deny controls
Maximum-performance mode and configuration sync for high availability

The sale starts October 12

From October 12 to November 30, 2026, save up to 35% on selected annual Pro plans and multi-license packs. We’ll share the full prices and purchase details when the sale opens.

If you’re considering Pro, take a look at your current setup and think about what you’ll need next. Already using Pro? Check your license term and plan ahead.

SafeLine Pro sale: October 12–November 30. Save up to 35%.

Learn more about SafeLine · Try the online demo · View SafeLine on GitHub

Dates and terms follow the English-language campaign page. Regional offers may differ.

How to Secure a Website Without Cloudflare

Thu, 08 Oct 2026 02:39:32 +0000

How to Secure a Website Without Cloudflare

Cloudflare is the default answer to "how do I secure my site," but it isn't the only one — and it isn't always the right fit. If you'd rather keep control of your infrastructure, avoid a third-party sitting between you and every visitor, or just want a free starting point, you can secure a website without Cloudflare using a self-hosted stack.

Here's the layering that actually matters.

The security layers (none Cloudflare-dependent)

TLS everywhere. Terminate HTTPS with a free certificate (Let's Encrypt or your CA of choice). Encrypted transport is table stakes, not a feature you rent.
A WAF in front of your app. This is the layer Cloudflare's firewall usually provides. You can self-host it instead: a WAF like SafeLine runs as a reverse proxy in front of your service and filters injection, XSS, and bot traffic before it reaches your code.
Rate limiting and bot management. Throttle abusive clients and separate automated traffic from real users at the edge.
Hardened DNS and registrar. Lock your domain (registrar lock), use a reputable DNS provider, and restrict zone edits.
Patching and backups. Most breaches exploit known vulnerabilities in unpatched software. Keep dependencies current and back up regularly.

Where SafeLine fits as the WAF layer

SafeLine is a self-hosted WAF by Chaitin. Its free Community Edition runs on your own hardware and covers up to 10 apps at 800 QPS, which is enough for most sites. It sits in reverse-proxy mode in front of your app, so every request is inspected before it hits your code — the same job Cloudflare's firewall does, just on infrastructure you control.

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

After install, open the console at https://<your-server-ip>:9443, add your site, and point its upstream at your app. You now have a filtering layer in front of your traffic without handing your traffic to a third party.

The honest trade-off

Cloudflare also brings a global CDN and very large-scale DDoS scrubbing capacity. A self-hosted WAF handles the application layer (injection, XSS, bots, abuse) extremely well, but for nation-state-sized volumetric floods you'd still want upstream/network mitigation. For the overwhelming majority of sites — business apps, blogs, APIs, internal tools — a self-hosted WAF plus the hygiene above is a complete, Cloudflare-free security posture.

FAQ

Is a self-hosted WAF harder to run than Cloudflare?

It's a different operational model: you own the box instead of a dashboard. The install is one command, and day-to-day it runs as a background service.

Do I lose DDoS protection without Cloudflare?

You keep application-layer protection (the attacks that actually hit web apps). For massive volumetric attacks you'd add network-level mitigation, but most sites don't face those.

Can I still use a CDN?

Yes — pair a CDN for static delivery with SafeLine in front of your dynamic origin. They're complementary, not exclusive.

Is the WAF free?

The Community Edition is free to run indefinitely and covers up to 10 apps at 800 QPS.

That's it — a complete security stack you control, with no Cloudflare required.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Self-Hosted WAF with a Low False Positive Rate: Why It Matters

Wed, 30 Sep 2026 03:25:50 +0000

Self-Hosted WAF with a Low False Positive Rate: Why It Matters

When you shop for a WAF, the headline number everyone shows is detection rate — how much attack traffic it catches. That's important, but it's only half the story. The other half is the false positive rate (FPR): how often the WAF wrongly flags legitimate traffic as an attack. A WAF that blocks 100% of attacks but also blocks 20% of your real users is worse than no WAF at all.

If you self-host, a low-FPR WAF protects your traffic without becoming a daily source of "why is the site down?" tickets. Here's what to look for.

What a false positive actually costs

A false positive is a real, innocent request — a customer's login, a partner's API call, a search query with an odd character — that the WAF drops because it looked malicious. The consequences:

Lost conversions — blocked customers don't retry, they leave.
Broken integrations — a partner API call rejected mid-flow.
Alert fatigue — your team starts ignoring the WAF because it "always complains."

High FPR pushes teams to loosen rules until the WAF stops helping. Low FPR means you can keep protection tight without breaking the business.

Why some WAFs trip on false positives

Traditional signature-based WAFs match requests against a list of known attack patterns. That's brittle: an unusual-but-valid input — a SQL-looking string in a search box, an encoded parameter — can trip a rule that was meant for something else. The more rules you stack to catch attacks, the more innocent traffic you risk catching too.

How a semantic engine lowers the rate

A semantic-detection engine (the approach SafeLine uses) doesn't just pattern-match. It analyzes the intent of a request — whether it's actually trying to exploit something — rather than whether it contains a suspicious-looking substring. Valid-but-odd requests pass; genuinely malicious ones are blocked. That distinction is what keeps the false positive rate low.

In SafeLine's published benchmark (its BlazeHTTP test against tens of thousands of attack payloads), the Community Edition posted a 0.07% false positive rate while still detecting the large majority of attacks — markedly lower than the double-digit FPR seen in some signature-rule configurations of traditional WAFs in the same test. The point isn't the exact figure; it's that a semantic approach is designed to keep legitimate traffic flowing.

What to check before you commit

Request intent, not just signatures — ask whether the engine understands the request or just matches strings.
Tunable thresholds — you should be able to tighten or loosen without rewriting rules by hand.
Transparent logs — when something is blocked, you need to see why, fast.
Self-hosted fit — run it where your traffic already flows, with no per-request billing.

Deploying it

Bring up SafeLine as a reverse proxy in front of your app:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

In the console at https://<your-server-ip>:9443, add your site, point its upstream at your app, and let the detection engine filter traffic. Review the logs for a day of real traffic, allowlist any legitimate patterns that surface, and you have tight protection with minimal noise.

FAQ

Is a low false positive rate the same as high detection?

No — they're independent. A WAF can be great at one and poor at the other. You want both: catch the attacks and let real traffic through.

Should I trust a vendor's benchmark number?

Treat published benchmarks as directional, not gospel — your traffic is the real test. Run the WAF in front of live traffic and watch the logs before drawing conclusions.

Will a semantic engine ever false-positive?

Any filter can, on sufficiently unusual input. The advantage is far fewer of them, and clear logs make the rare miss easy to spot and allowlist.

Is this free to self-host?

The Community Edition is free to run indefinitely and covers up to 10 apps at 800 QPS, with the same detection engine as the paid tiers.

That's it — you can run tight WAF protection without flooding your team with false alarms.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Prevent Application-Layer DDoS Attacks on Your Web App

Mon, 28 Sep 2026 02:25:39 +0000

How to Prevent Application-Layer DDoS Attacks on Your Web App

Most people picture DDoS as a firehose of garbage packets aimed at a network. But the attacks that actually take down modern web apps are usually quieter: application-layer (L7) DDoS, where the flood looks like normal traffic. It's a wave of legitimate-looking HTTP requests designed to exhaust your app, database, or upstream.

Because the requests aren't obviously malicious, a plain firewall can't tell them apart from real users. A WAF in front of your app is the right place to draw the line. Here's how.

Why L7 DDoS is tricky

A network-layer DDoS is easy to spot — it's just volume. An application-layer attack blends in:

Requests hit real URLs with valid headers.
They may come from many IPs (a botnet), so blocking by address alone doesn't scale.
The damage comes from cost — each request triggers expensive work: a database query, a render, an API call.

The goal isn't to crash your server with bandwidth; it's to make your app do so much real work that it falls over.

The defense playbook

A few controls together blunt most L7 floods:

Filter the obviously bad. Drop malformed requests, known attack signatures, and malformed HTTP before they reach your app.
Rate limit per IP and per path. Cap how much any single client can ask of a given endpoint.
Manage bots. Identify and throttle automated clients; let humans through.
Cache aggressively. Serve static and repeatable responses from cache so they never reach your app.
Scale the origin behind the WAF so a spike doesn't instantly exhaust capacity.

Where SafeLine fits

SafeLine is a self-hosted WAF that runs as a reverse proxy in front of your app, so every request is inspected before it reaches your code:

The semantic detection engine filters abnormal and malicious HTTP traffic, dropping the junk that would otherwise hit your app.
Rate limiting caps requests per client and per path, so a flood can't monopolize your origin.
Bot management separates automated traffic from real users, letting you throttle or block the flood without hurting legitimate visitors.
Because it runs at the edge of your stack, malicious requests are stopped early — before they trigger expensive backend work.

SafeLine won't replace a full CDN-scale DDoS solution for nation-state-sized floods, but for the common L7 attacks that knock over small-to-mid web apps, it's a strong, self-hosted first line of defense.

Deploying it in front of your app

Bring up SafeLine as the proxy in front of your service:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

In the console at https://<your-server-ip>:9443, add your site and point its upstream at your app. Enable bot mitigation and set sensible rate limits on your heaviest endpoints. Traffic is now filtered and throttled at the edge, so a flood has to get past the WAF before it can touch your app.

FAQ

Can a WAF stop all DDoS attacks?

It handles the common application-layer floods that target web apps. Very large volumetric attacks also need upstream/network mitigation, but most real-world incidents are L7 — exactly what a WAF addresses.

Won't rate limiting hurt real users during a spike?

Set limits above normal human patterns. Legitimate traffic sails through; only abusive automated volume gets throttled.

Does this replace caching and scaling?

No — they're complementary. SafeLine filters and throttles; caching and scaling absorb the rest. Together they're far more resilient than any one control.

Is this hard to self-host?

The one-line installer brings up the whole stack as containers, and the console walks you through adding a site.

That's it — your app now has a filtering and rate-limiting layer in front of it.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Why I prefer systemd timers over cronjobs

Thu, 24 Sep 2026 13:39:29 +0000

Most users would schedule their tasks using a cronjob, and that's perfectly reasonable

Introduction

I will assume you are running on a linux machine with systemd (which you should be if you're running on a server), other init systems such as runit or openRC are not taken into consideration

The content is mainly targeted for servers, however you can apply these concepts to your personal machines

What is a cronjob

Cronjobs are essentially used for scheduling tasks at certain intervals or exact time(s)

The task could be a shell script, a command, a call, anything you may need

Example Usage

Creating a cronjob is very easy

Run crontab -e

Paste this:

*/1 * * * * echo "$(date -Iminutes) Running" >> /tmp/cronjob_running.txt

This would echo the current datetime in ISO format to file /tmp/cronjob_running.txt every minute

Simple, easy and straightforward

Problem

This works fine and well for personal, simple or non important tasks.

But let's take this job:

0 0 * * * /usr/local/sbin/postgresql_backup.sh >> /var/log/postgres/backups/backup.log 2>&1

This job would run the postgresql_backup.sh script every day at 00:00 and output the logs AND errors to /var/log/postgres/backups/backup.log

What happens when the machine goes down at 00:00? or something even more probable, cron's systemd unit (like cronie) stops or does not start because someone forgot to (re)enable it.

Answer: The job never runs

Systemd timers

What is systemd

It's the core init unit of your linux system, when your machine boots up, the kernel will load it with a pid of 1

A systemd timer is, as the name suggests, a timer that is managed by systemd

So basically, the solution is already integrated into your Operating System, you're just not using it!

What's more, they have more precision than cronjobs do and they support much finer scheduling granularity.

How to create these timers

Now I'll be honest, creating them is a bit of a pain and not as quick as cronjobs, but we'll talk about the differences at the end!

For the sake of simplicity I'll keep the example very straightforward, but note you can really get a bit more complex with these

First, you create a user systemd unit by running:

systemctl --user edit --force --full example-unit.service

We're creating a user scoped timer for this example, but for more serious work like a database backup, use sudo and omit user, like this: sudo systemctl edit --force --full example-unit.service

The --force --full flags are used to create the unit if it doesn't exist, I use the systemctl edit command so that if we exit with an empty file, we won't have issues, plus it does create a backup for us which is handy

Then put this into the content

[Unit]
Description=Our Example systemd Unit

[Service]
ExecStart=/usr/bin/echo "Hello There!"

[Install]
WantedBy=default.target

Save and exit
Reload your systemd daemon:

systemctl --user daemon-reload
Run the unit

systemctl --user start example-unit.service

Nothing happens, why? where's my output?

You inspect your service like any other systemd unit.. with status subcommand

Run this

systemctl --user status example-unit.service

You get something similar to this:

But where's the schedule here?
Well, this is why I said

creating them is a bit of a pain and not as quick as cronjobs

The Timer

Finally, it's time we create the actual timer unit

Run this command:

systemctl --user edit --force --full example-unit.timer

The same goes here, omit the --user flag and add sudo if doing a system wide timer!

Add this

[Unit]
Description=Running Our Example Unit regularly

[Timer]
OnCalendar=*:0/1
# This here is our magic flag
Persistent=true
Unit=example-unit.service

[Install]
WantedBy=timers.target

Save and exit
Run this command

systemctl --user start example-unit.timer

NOTE: We're only starting the timer here, if we reboot the machine the timer will not persist
For the timer to remain enabled, you do systemctl --user enable --now example-unit.timer

Here's what you get:

This will run our unit every minute, and with our magic Persistent=true even if your machine goes down, or for whatever reason it gets missed due to some random bit flipping, your timer WILL run when it gets the chance

It stores the last execution timestamp on disk. When the timer becomes active, systemd checks this file, and if the target trigger time passed while the system was powered off it immediately triggers the service.

Comparing systemd timers to other solutions

Now for more informed readers, you may know of anacron which is a perfectly reasonable solution however there are some differences you need to be aware of.

Here's a comparison to systemd timers, cronjobs and anacron

Solution	Simple to create	Flexible Scheduling	Runs on missed tasks
Systemd	❌	✅	✅
Anacron	✅	❌	✅
Cronjob	✅	✅	❌

anacron doesn't have that much flexibility, they have daily basis checkup, which you may or may not want, so beware of that

Systemd timers Scheduling

You may have noticed that we used the OnCalendar keyword in our timer, it's not the only one! there are more things you can configure

Monotonic Timers

These basically run relative to something, it can be relative to system boot, it can be time since the unit was activated!

Here's a small table of keywords and schedules you can have that I borrowed from this great Article

Keyword	Meaning
OnActiveSec	Schedule the task relative to the time when the timer unit itself is activated
OnBootSec	Schedule task relative to the system boot time
OnStartupSec	Schedule the task relative to the time when systemd started
OnUnitActiveSec	Schedule the task relative to the last time the service unit was active
OnUnitInactiveSec	Schedule the task relative to the last time the service unit was inactive

Seconds are used as the default unit of time. We can specify a different unit after the value (e.g. 15m for fifteen minutes)

Realtime Timers

These are the ones that use the OnCalendar keyword

The basic syntax is:

OnCalendar=Mon *-*-* 12:30:00
           │   │ │ │ │  │  │
           │   │ │ │ │  │  └── SECOND
           │   │ │ │ │  └───── MINUTE
           │   │ │ │ └──────── HOUR
           │   │ │ └────────── DAY OF MONTH
           │   │ └──────────── MONTH
           │   └────────────── YEAR
           └────────────────── WEEKDAY

Conclusion

Systemd Timers are great for scheduling important tasks or interacting with a daemon that you already installed.
So are they the solution for everything? No, they're cumbersome to create and honestly I don't like the way it's handled.

Use the right tool for the job, if it's a business critical backup that runs twice a day? a very important data collection task? Use systemd timers, if it's simply another task that would not harm if it was missed once, use cronjobs, they're much easier to create

There are many things that I have not mentioned in this article, and things I didn't go into depth into but I hope this article helps future engineers with their journey in automating and scheduling

Free WAF for Self-Hosted Apps: Protect Your Stack Without the Bill

Thu, 24 Sep 2026 02:29:13 +0000

Free WAF for Self-Hosted Apps: Protect Your Stack Without the Bill

If you self-host your apps, you've already committed to owning the infrastructure. That's good news for security: it means you can drop a free WAF in front of your stack without signing up for another monthly bill. For anyone running services on a VPS, a homelab, or a small cloud instance, a self-hosted WAF is some of the cheapest insurance you can buy.

Here's how to protect self-hosted apps for free, and why SafeLine's Community Edition is a practical default.

Why self-hosted apps need a WAF

Any app you expose to the internet — a dashboard, an API, a CMS — is a target. Attackers scan for injection flaws, exposed admin panels, and known exploits automatically, around the clock. A WAF sits in front of your app and filters that traffic before it reaches your code.

The catch with many WAFs is the price: cloud services bill per request or per protected app, which adds up fast across a self-hosted stack with several services. Running the WAF yourself removes that line item.

What "free" should still give you

Not all free WAFs are equal. A free option is only worth it if it does the job:

Blocks the common web attacks (SQL injection, XSS) by default.
Mitigates automated bots and credential stuffing.
Deploys in minutes, not days.
Runs on hardware you already have.

If a "free" tool needs you to write a pile of rules before it blocks anything, it isn't really free in time.

SafeLine Community Edition: a free self-hosted pick

SafeLine is a self-hosted WAF by Chaitin, and its Community Edition is free to run indefinitely. It covers up to 10 applications at 800 QPS, which is plenty for a personal stack or a small set of self-hosted services.

Under the hood it uses a semantic detection engine — it analyzes request intent rather than matching a static signature list — to catch injection and bot traffic. You get the protection without becoming a rule-tuning specialist.

Deploying it in a few minutes

The one-line installer brings up the full stack (management console, detection engine, database, and cache) as containers:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Then:

Open the console at https://<your-server-ip>:9443.
Add a site and set its upstream to your app (for example http://127.0.0.1:8080).
Point your DNS or reverse proxy at SafeLine's listener.

That's it — traffic now flows through the WAF before reaching your app. The minimum host is modest: about 1 CPU, 1 GB RAM, and 5 GB disk.

When free stops being enough

The Community Edition's two caps are 10 apps and 800 QPS. If you run more services or push more traffic, the paid tiers lift those limits — Lite raises the app cap, and Pro removes it entirely — while keeping the same detection engine. You upgrade for headroom, not for better protection.

FAQ

Is this really free, or a trial?

The Community Edition is free to run with no time limit. The only constraints are the 10-app and 800-QPS ceilings.

Can it sit in front of multiple apps?

Yes — up to 10 on the free tier. Each protected site or API counts as one app.

Do I need to write detection rules?

No. The semantic engine blocks common attacks out of the box; you tune only if you want to.

What if I outgrow the free tier later?

Upgrading is a licensing change that raises the caps; your configuration and protected sites carry over.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Best Self-Hosted WAF for Small Business: What to Look For

Thu, 24 Sep 2026 02:27:39 +0000

Best Self-Hosted WAF for Small Business: What to Look For

Small businesses get attacked at roughly the same rate as everyone else, but they rarely have a security team to absorb the hit. A web application firewall (WAF) is one of the highest-leverage defenses you can put in front of your site — and for a small business, a self-hosted WAF is often the most sensible way to run one.

This guide walks through what actually matters when you're picking a WAF for a small business, and why a self-hosted option like SafeLine's free Community Edition deserves a serious look.

What a small business actually needs from a WAF

Enterprise WAF buying guides are full of features most small businesses will never touch. Strip it back to what you really need:

Protection from the common stuff — SQL injection, cross-site scripting, and automated bots are the daily background noise of the internet. A WAF should block these out of the box, without you hand-writing rules.
Easy to set up — if deployment takes a senior engineer a week, it won't happen. The best WAF for a small business is the one you'll actually turn on.
Low or no cost — small margins mean every recurring subscription is a decision. Free is a strong default when the protection is real.
Minimal upkeep — you don't have spare cycles to babysit it. It should run quietly once configured.

Why self-hosted fits small businesses

A self-hosted WAF runs on infrastructure you already control — a spare VM, a small VPS, or a node in your existing stack. That changes the economics in your favor:

No per-app or per-request billing. Cloud WAFs often charge by traffic or by the number of protected services. Self-hosted shifts that to a flat server cost you're likely already paying.
Data stays with you. Traffic inspection happens on your own hardware, which matters if you have residency or compliance preferences.
No lock-in. You're not tied to one vendor's console, pricing changes, or feature gates.

The trade-off is real but small: you own the box, so you handle the host. For most small businesses that's a fair exchange for removing a monthly bill.

How to evaluate options

When you compare self-hosted WAFs, score them on four things:

Detection quality — does it actually catch injection and bot traffic, or just pattern-match a stale signature list?
Install friction — how many commands from zero to a protected site?
Resource footprint — can it run on a modest box alongside other services?
Price ceiling — what do you pay as you grow?

Where SafeLine fits

SafeLine is a self-hosted WAF by Chaitin. Its free Community Edition is a strong fit for small businesses because it covers the needs above without a subscription:

Free forever, self-hosted, and covers up to 10 applications at 800 QPS.
Ships with a semantic detection engine that blocks SQL injection, XSS, and bots without signature tuning.
Installs with a single command and runs on a modest host — roughly 1 CPU, 1 GB RAM, and 5 GB disk at minimum.
Management console on https://<your-server-ip>:9443.

That combination — free, low-footprint, and genuinely protective — is exactly what most small businesses are looking for.

Getting started

The fastest path is the one-line installer, which brings up the whole stack (console, detection engine, database, cache) as containers:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Open the console, add your first site, and point its upstream at your app. If you grow past 10 apps or 800 QPS, paid tiers (Lite and Pro) raise the ceiling without changing how the WAF behaves.

FAQ

Do I need a WAF if I already use HTTPS?

Yes. HTTPS encrypts traffic; it doesn't stop an attacker from sending a malicious request to your login form. A WAF inspects what's inside the request.

Is the free tier enough for a small business?

Often, yes — 10 apps at 800 QPS covers a typical small-business footprint. Upgrade only when you outgrow those caps.

Will running it myself be a lot of work?

Minimal. Once installed and pointed at your sites, it runs as a background service. You check the console occasionally, like any other server component.

What if I don't have a spare server?

A small VPS (the size that runs the console) is enough to start, and it can often share the host with other lightweight services.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

SafeLine WAF Community Edition Limitations: What You Get for Free

Wed, 23 Sep 2026 02:24:36 +0000

SafeLine WAF Community Edition Limitations: What You Get for Free

SafeLine ships a free Community Edition that you can run on your own server with no time limit and no feature trial. That makes it one of the few self-hosted WAFs you can actually put in front of production traffic without pulling out a credit card. But "free" does come with a ceiling, and it's worth knowing exactly where that ceiling sits before you commit.

This article walks through what the Community Edition includes, the two hard limits you'll hit, and the point at which stepping up to a paid tier makes sense.

What the Community Edition actually gives you

The free tier is not a stripped-down demo. It's the same detection engine that powers the paid plans, just with capacity caps. Concretely, the Community Edition covers:

Up to 10 applications behind the WAF.
Up to 800 QPS (queries per second) of protected traffic.
The core semantic detection engine — the part that blocks SQL injection, XSS, bot traffic, and common web exploits without signature tuning.
A management console, logs, and the reverse-proxy mode that sits in front of your upstream services.

If your setup fits inside those two numbers, you get the full protective value of SafeLine at zero cost. For a personal site, a small portfolio of internal tools, or a handful of low-traffic services, that's often the entire story.

Where the limits actually bite

There are exactly two hard constraints on the Community Edition, and both are about scale rather than features:

10 applications. Each protected site or API counts as one app. Once you pass ten, you can't add more on the free tier.
800 QPS. This is the throughput ceiling for inspected traffic. Bursts above it won't be denied outright, but you've left the envelope the free tier is sized for.

Notice what isn't limited: there's no expiry, no blocked attack category, and no "contact sales after 14 days" wall. The limits are capacity, not capability. That's a meaningful difference from vendors who gate the actual protection behind a paid plan.

When it's time to move up

If you're consistently near either cap — or you simply expect to grow past it — SafeLine offers two paid tiers that lift the ceilings rather than change how the WAF behaves:

Lite — roughly $10/month, raising the cap to 20 applications. A small step up for growing teams.
Pro — roughly $100/month, with unlimited applications for larger estates.

Because the detection engine is identical across tiers, upgrading is about headroom, not about suddenly getting better protection. You move up when your app count or traffic volume demands it, not because the free tier is "missing" a feature.

Getting started on the free tier

The fastest way to see the Community Edition in action is the one-line installer, which brings up the whole stack (console, detection engine, database, cache) as containers:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Once it finishes, open the console at https://<your-server-ip>:9443, add your first site, and point its upstream at your app. You're now protecting up to 10 applications at 800 QPS for free.

FAQ

Is the Community Edition a time-limited trial?

No. It's free to run indefinitely. The only constraints are the 10-app and 800-QPS ceilings.

What happens if I exceed 800 QPS?

The limit is a sizing ceiling, not a hard cutoff that starts dropping traffic. But if you're consistently above it, a paid tier gives you the headroom to run comfortably.

Do I lose any protection features on the free tier?

The detection capabilities are the same across tiers. Paid plans raise the app and throughput limits; they don't unlock a separate set of WAF features.

Can I switch from Community to Pro later?

Yes. Since the engine is the same, moving up is a licensing change that lifts the caps — your configuration and protected sites carry over.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How we migrated an Italian logistics company from Windows to Linux: a real case study

Tue, 22 Sep 2026 12:57:16 +0000

In early 2026 I migrated a logistics and transport company in Bergamo, Italy from a fully proprietary setup to Linux and open source. Five workstations, five employees, zero technical background on their side. Here is what we did, what happened, and what I learned.

The starting point

The company was running Windows on every workstation, Microsoft Office for documents, a third-party antivirus renewed annually, and an external IT technician called in every time something broke. They had no internal IT knowledge and no interest in acquiring any. They just wanted things to work.

Their main pain points were slow machines, frequent crashes after Windows updates, and a recurring bill that kept growing without any visible improvement.

What we installed

I replaced everything with a fully open source stack:

Kubuntu as the operating system on all five workstations
LibreOffice in place of Microsoft Office
Thunderbird for email
Nextcloud for file sharing and internal document management, self-hosted on a server in Italy
Mattermost for internal team communication
pfSense as the network firewall
WireGuard for VPN access
Automated encrypted backups running nightly

Total recurring licence cost after migration: zero.

The migration process

The full migration took approximately one week. I configured everything on a test machine first, validated all workflows with the team, then rolled out workstation by workstation during off-hours to avoid interruptions.

The biggest challenge was not technical. It was psychological. People are used to what they know. I spent as much time sitting with each employee and showing them that LibreOffice opens their Word files and Nextcloud works like Google Drive as I did on the actual technical setup.

After three days they stopped asking about Windows.

Results after six months

Six months in, the company has not called me for a single ordinary technical issue. The machines are faster. Updates do not break anything. There have been zero security incidents.

The most concrete result: each employee recovered roughly one hour per day that was previously lost to slowdowns, crashes and waiting for the external technician. On five people that is five hours a day returned to productive work.

Licence costs are gone. The infrastructure belongs to them, not to a vendor.

Why this matters beyond one company

Most Italian SMEs are in the same situation. They pay recurring fees for software they do not own, store data on foreign servers subject to the US Cloud Act, and depend on vendors who can change the rules at any time.

Linux and open source infrastructure is not experimental. It is mature, stable, and ready for business use. The barrier is not technical. It is awareness.

I wrote the Zerolock Manifesto (https://zerolock.org) on exactly this topic. If you are working on similar migrations or have questions about the stack, I am happy to discuss in the comments.

How to Block Bad Bots with SafeLine WAF

Mon, 21 Sep 2026 02:29:37 +0000

How to Block Bad Bots with SafeLine WAF

Bad bots are everywhere: content scrapers, credential stuffers, vulnerability scanners, and spam senders. The trick is blocking the harmful ones without hurting good crawlers like Google. SafeLine does this with bot detection and a human-verification challenge at the edge.

The problem with a blunt block

Blocking by IP or user-agent alone breaks easily — bots rotate both. And a naive block can also catch search-engine crawlers you want indexing your site. You need to tell automated abuse apart from real users and legitimate bots.

Step 1 — Install SafeLine in front of your site

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Add your site as the upstream in the console at https://<safeline-ip>:9443.

Step 2 — Turn on bot protection

SafeLine detects automated behavior and can issue a bot challenge (a human-verification step) to clients that look suspicious. A real browser solves it once and proceeds; a scripted bot fails or gets throttled. Legitimate, well-behaved crawlers pass through normally.

Step 3 — Keep good bots working

Add allowlist entries for crawlers you trust (for example, Googlebot) so SEO and indexing are unaffected. SafeLine's heuristics handle the rest of the automated traffic.

Step 4 — Add rate limiting where it helps

Bot blocking pairs well with rate limiting for specific paths — /login against credential stuffing, or an API endpoint against scraping. Set a threshold and SafeLine slows or blocks clients that exceed it.

What you see

The dashboard breaks down bot vs. human traffic and shows which clients were challenged or blocked, so you can tune the allowlist with confidence.

FAQ

Will this hurt my SEO?

No — good crawlers are allowed through; only abusive automated traffic is challenged.

Can I allow specific bots?

Yes — allowlist by user-agent or other traits for crawlers you trust.

Does it stop credential stuffing?

Combined with rate limiting on login paths, yes.

Free tier?

The Community Edition covers 10 apps at 800 QPS for free.

That's it — abusive bots get challenged at the edge while real users and search engines sail through.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

How to Protect a Web Server with SafeLine WAF

Sun, 20 Sep 2026 01:42:16 +0000

How to Protect a Web Server with SafeLine WAF

A web server — Nginx, Apache, Caddy, or an app server behind them — faces the same internet as everything else: injection attempts, scanners, and bots. SafeLine sits in front of that server as a self-hosted WAF reverse proxy, filtering traffic before it reaches your web server.

The setup

Client → SafeLine (inspects) → your web server (upstream) → app

Your web server becomes the upstream. SafeLine receives public traffic on :80 / :443, decides what is safe, and forwards clean requests to wherever your server actually listens.

Step 1 — Install SafeLine

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

It runs as a container and is happy on a small host (1 CPU, 1 GB RAM, 5 GB disk minimum).

Step 2 — Point SafeLine at your web server

Open the console at https://<safeline-ip>:9443 and add a protected site:

Upstream server — your web server's address, e.g. http://127.0.0.1:8080 if it runs on the same host, or http://10.0.0.5:80 if it's elsewhere.
Domain — the hostname clients use.
Port — the public port SafeLine listens on.

Step 3 — Send traffic through SafeLine

Either repoint DNS for the domain to the SafeLine host, or move your web server off the public port (to a localhost port) and let SafeLine take it. Traffic now flows Client → SafeLine → web server.

What it blocks

SafeLine's semantic-analysis engine inspects request intent, not just signatures. Out of the box it blocks SQL injection, XSS, code/command injection, path traversal, and automated abuse — for any web server behind it, regardless of language or framework.

FAQ

Does it matter what web server I use?

No — Nginx, Apache, Caddy, and app servers all work the same way, since SafeLine operates at the HTTP layer in front of them.

Will legitimate traffic be blocked?

Rarely. If a specific route trips a false positive, add a whitelist rule for that path instead of disabling protection.

Free tier limits?

The Community Edition covers up to 10 apps at 800 QPS at no cost.

Can one SafeLine protect several web servers?

Yes — each protected site maps its own domain to its own upstream.

That's it — your web server now has a self-hosted WAF filtering traffic before it ever arrives.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

How to Configure SafeLine WAF as a Reverse Proxy

Fri, 18 Sep 2026 10:19:28 +0000

How to Configure SafeLine WAF as a Reverse Proxy

SafeLine is a self-hosted WAF that works as a reverse proxy by design: it terminates your public traffic, inspects every request, and forwards only clean traffic to your real web server. This guide walks through configuring that proxy flow so your existing apps stay exactly where they are.

How the traffic flows

Client → SafeLine (listens :80 / :443) → upstream origin server (your app)

SafeLine sits in front. Your web server (Nginx, Apache, a Docker app, whatever) becomes the upstream — the server SafeLine forwards to. The app never sees unfiltered traffic, and you don't have to change your app's code.

Step 1 — Install SafeLine

Run the one-line installer on a host that can reach your upstream server:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

It pulls the container, starts the management console, and is happy on a small box (1 CPU, 1 GB RAM, 5 GB disk minimum).

Step 2 — Open the console and add a site

Open https://<safeline-ip>:9443 and go to the protected-sites section. Add a site with three pieces of information:

Upstream server — where your real app listens, e.g. http://127.0.0.1:8080 (if it runs on the same host) or http://192.168.1.20:80 (if it's on another machine).
Domain — the hostname clients use, e.g. app.example.com.
Port — the port SafeLine should listen on publicly (usually 80 for HTTP, 443 if you attach a certificate).

SafeLine now knows: "when traffic arrives for app.example.com on port 80, inspect it and forward to http://127.0.0.1:8080."

Step 3 — Point traffic at SafeLine

Two common ways:

DNS: point app.example.com to the SafeLine host's IP instead of the origin's IP.
Port / firewall: if SafeLine is on the same host, stop your web server from binding the public port and let SafeLine take it, with the web server moved to a localhost port (the upstream above).

Either way, new requests now pass through SafeLine first.

Step 4 — Verify and tune

The dashboard shows real-time request logs: allowed, blocked, and challenged. SafeLine's semantic-analysis engine blocks SQL injection, XSS, and automated abuse without signature tuning. If a specific path needs custom handling (a legacy API that trips a false positive), you can add a whitelist rule for that route.

Why this mode is convenient

Your app stays unchanged — SafeLine is purely in the network path.
One SafeLine instance can proxy multiple upstreams (the free Community Edition covers 10 apps).
You get a single inspection point and a single dashboard for everything behind it.

FAQ

Does SafeLine replace my Nginx?

Not necessarily. Nginx can stay as the upstream; SafeLine just inspects traffic before it. Many run Nginx → SafeLine → app, or SafeLine → Nginx → app.

What about HTTPS?

You can terminate TLS at SafeLine and forward plain HTTP to the upstream, or forward HTTPS through to the upstream untouched.

Is there a request limit on the free tier?

The Community Edition handles up to 800 QPS across 10 protected apps at no cost.

Can I run more than one upstream per SafeLine?

Yes — each protected site maps its own domain to its own upstream.

That's it — your WAF is now running in front of your apps as a reverse proxy.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

How to Deploy a Self-Hosted WAF Alternative to Cloudflare

Wed, 16 Sep 2026 03:00:26 +0000

How to Deploy a Self-Hosted WAF Alternative to Cloudflare

A self-hosted WAF means the inspection engine runs in your own environment, not a vendor's cloud. For teams that want control, privacy, or predictable cost, that is the whole point — and SafeLine is built exactly for this.

What "self-hosted" buys you

Traffic never leaves your network for inspection.
No per-request billing.
Your own dashboard, logs, and policy.

SafeLine specifically

SafeLine is deployed as a container that acts as a reverse proxy. Its semantic-analysis engine inspects each request for attack intent, blocking SQLi, XSS, and automated abuse before it reaches your app. The web console lives at https://<ip>:9443.

Comparing to SaaS WAFs

SaaS WAFs (Cloudflare, AWS WAF) win on zero-infra and global edges. Self-hosted wins on control and cost. SafeLine narrows the operational gap with a fast container install and a free Community Edition (10 apps / 800 QPS).

FAQ

What are the hardware requirements?

1 CPU, 1 GB RAM, 5 GB disk — modest.

Can it sit behind my existing load balancer?

Yes; place it as the inspection tier before your upstreams.

How do I monitor it?

The dashboard shows real-time logs and alerts; you can also export for your own SIEM.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

SafeLine WAF: A Self-Hosted Alternative to Cloudflare You Can Run Yourself

Mon, 14 Sep 2026 11:05:54 +0000

When people talk about protecting a website from bots, scrapers, and injection attacks, Cloudflare is usually the first name that comes up. It's a solid service — but it's not the only path, and for some teams it isn't even the best one. If you care about where your traffic flows, how much you pay as you grow, and keeping your logs on your own infrastructure, a self-hosted WAF deserves a serious look. SafeLine WAF is one option in that category, and here we'll see where it fits as an alternative to a cloud WAF like Cloudflare.

Why look beyond a cloud WAF

Cloud WAFs are convenient: sign up, point your DNS, done. But that convenience comes with trade-offs:

Your traffic routes through someone else's network. For teams with data-residency requirements or simply a preference for self-control, that's a real concern.
Cost scales with usage. Many cloud WAFs bill per request or per feature tier, so a traffic spike can mean a surprising invoice.
You depend on their UI and rate limits for day-to-day changes.

None of that is a reason to avoid cloud WAFs outright — but it explains why a growing number of teams evaluate self-hosted options.

What SafeLine WAF is

SafeLine WAF is a self-hosted Web Application & API Protection (WAAP) solution by Chaitin. Instead of running in a vendor's cloud, it runs on your own infrastructure — typically deployed with a single Docker Compose file. Key points:

Free to start. The Community Edition covers up to 10 applications and 800 QPS at no cost, with no per-request billing.
Paid tiers for scale. Lite (~$10/month, 20 apps) and Pro (~$100/month, unlimited apps) unlock more capacity and features.
You keep your data. Traffic inspection and logs stay on your servers.
Flexible rules and an open API let you script policy and site management instead of clicking through a UI.

SafeLine vs Cloudflare: the practical differences

Dimension	Self-hosted (SafeLine)	Cloud WAF (Cloudflare)
Where traffic is inspected	Your infrastructure	Cloudflare's network
Cost model	Predictable (your servers)	Per request / per tier
Log location	On your servers	Vendor's platform
Rule changes	API or UI, your pace	Vendor's UI and limits
Setup	Docker Compose	DNS change + account

This isn't "one is better" — it's about fit. Cloudflare shines when you want a hands-off CDN + WAF combo. SafeLine shines when you want control, predictable cost, and data sovereignty.

Getting started

Installation is a one-liner (English install):

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

After deployment, the management console is available at https://<your-server-ip>:9443. You can explore the interface without installing anything via the live demo.

SafeLine sits in front of your sites as a reverse proxy, so it can filter and block malicious requests before they reach your application — the same job a cloud WAF does, just on infrastructure you own.

Who should consider it

A self-hosted WAF is a great fit if you already run your own servers and have someone comfortable with Docker, Nginx, and basic monitoring. A single node protecting a handful of sites is close to plug-and-play; a multi-node cluster protecting many production domains benefits from investing in monitoring and runbooks.

FAQ

Is SafeLine actually free?

The Community Edition protects up to 10 applications at 800 QPS with no request-based fees. Paid tiers add capacity and features when you outgrow it.

Do I have to replace my existing reverse proxy?

No. SafeLine works as a reverse proxy in front of your services, so you can keep Nginx or your current setup behind it.

How is this different from just using Cloudflare?

The core difference is ownership: inspection and logs stay on your infrastructure, and cost is predictable rather than tied to request volume.

Can it handle production traffic?

Yes, with the right edition and sizing. Start on Community for lower volumes, then move to Lite or Pro as traffic grows.

Thinking about bringing your edge protection in-house?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

What Happens When Every AI Tool You Use Shares One Brain?

Mon, 07 Sep 2026 00:04:43 +0000

I was working across a growing pile of AI tools, and each one built its own little fiefdom of knowledge. Claude had Projects, Perplexity had Spaces, and my coding agents knew whatever happened to be on the local filesystem. My notes and todo lists lived in Obsidian, my bright ideas in AI "projects," and my coding ideas in chat history I could never find. Each tool knew exactly what I'd told it in that session and nothing more, so every new conversation started with me re-explaining the history of what I was doing.

Then my colleague and friend Siva showed me his second brain. He'd built his on Notion, wired his AI tools into it, automated capturing information, and could ask questions against everything he'd collected. I had to have one.

But not his... My constraints ruled his out (and I just had to be different, because). No new notetaking tool: I already lived in Obsidian and wasn't migrating (again). No cloud subscription to glue it together. And whatever I built had to run on my home server, because I run one anyway and self-hosting is half the fun (pain?).

What I ended up with is a plain folder of Markdown files fronted by a Model Context Protocol (MCP) server that lets any AI agent read and search it, synced to my devices through Obsidian Sync. My personal AI tools now share one brain. What follows is how I built it, what I almost built instead, and what a month of living with it has been like.

Key insights

It works way better than I anticipated. Agents move around the vault comfortably, powered mostly by keyword (lexical) and semantic search covering for each other: one finds the exact phrase, the other lets me be vague and "let the AI figure it out."
Plain Markdown turned out to be the universal language between AI and human. Every tool reads it, every tool writes it, and I can open any note myself without going through an agent.
A month in, the vault powers all my side quests and personal knowledge work, and I can't work without it now.

What I considered

The AI-first memory platforms. Tools like mem0, Supermemory, or LangMem pitch themselves as second brains, but they're built as memory for agents: the AI reads and writes, and human interaction isn't at the forefront. Those have real value, and I even piloted mem0, but I wanted a personal wiki I could browse and edit myself.

The Obsidian MCP servers. Since my notes already lived in Obsidian, this looked like the shortest path. However, everything I found either required the Obsidian desktop app running (via the Local REST API plugin), spoke stdio only, or needed a proxy bridge glued on top. All I really needed was a Markdown MCP: something that treats a folder of Markdown files as the vault, with search and auth. Requiring a desktop app to keep a headless server alive sounded fragile (which is what Notion solves out of the box, FWIW).

Cloud-native platforms. Notion and friends are probably the fastest way to get going, but adopting one meant a new notetaking tool and a cloud subscription: the two constraints I started with. Everything I had lived in Obsidian, so "quick to start" would have come with a migration attached and a bill.

Nothing really fit, so I assembled my own stack.

The build

The assembled stack is one Docker Compose file on my home server, three services:

services:
  mcp:         # markdown-vault-mcp: serves the vault over MCP, with search
  sync:        # obsidian-headless CLI in a Node container: keeps my devices in sync
  cloudflared: # Cloudflare Tunnel connector: outbound-only exposure

(Trimmed for print. The real one has the usual volumes, env vars, and healthchecks.)

The mcp service runs markdown-vault-mcp, an open-source MCP server that treats a plain folder of Markdown files as the vault. It adds keyword search via FTS5, and pointing it at an embedding model adds semantic search; embedding the entire vault costs pennies. The sync service runs the official obsidian-headless CLI against the Obsidian Sync subscription I already had, so anything an agent writes lands on my phone and laptops like any other note. I did have to do an initial "login and setup" ritual inside the sync container, but it has run seamlessly since.

The cloudflared service deserves some emphasis. A Cloudflare Tunnel is outbound-only: my server calls out to Cloudflare, so there are no inbound ports to open and no public IP to worry about. When the stack is down, nothing is exposed at all, which is way better than leaving a forwarded port hanging around "temporarily" for months.

For auth, I didn't want to hand a pre-shared API key to every tool I connect, so I put OAuth in front of it through Google, using my GCP account. Connecting a new tool now means a Google login instead of a copy-pasted secret.

Two key decisions I made. The MCP server mounts only a subfolder of the vault, so agents can't see (ruin) anything outside it, while the sync service mounts the root. Consistency across tools lives in the vault itself: an AGENTS.md at the root, plus instructions the server ships to every client when it connects. Consistent rules across agents for consistent results.

One side confession: in the first days, performance was awful, so I spent way too much time blaming a non-existent Cloudflare outage instead of the actual culprit: the Rancher Desktop VM was undersized for the vault and everything else running on it. Scaled it up, and the flakiness vanished.

Connecting the agents

With the stack running, connecting a tool is routine: add an MCP connector, auth with Google, start hoarding brilliant ideas and lists. I connected Perplexity right away and it's been my primary workhorse since. Grok, Antigravity, and GitHub Copilot quickly followed, so I could take one of those ideas to implementation. Gemini Spark is connected too, though it's only run simple tests so far.

I did not connect Claude and Claude Code. Those are work tools, and I try my best to keep work and personal systems apart. All of my clients now have their own AI use policies, security requirements, NDAs and more, so having their IP leak into a side quest would be bad.

Since the server ships the same instructions to every client at connect time, each tool plays by the same rules. When I change the rules, I change them once. This was one of the wise decisions from the OG designers of MCP.

A month in

The vault has settled in as the default starting point for my side quests. Every project gets its own notes, so picking a quest back up after weeks of neglect no longer means digging through extensive chat histories. My to-do list lives there, and so does the running list of "brilliant ideas," which grows much faster than I'll ever build them.

The surprise of the project has been the search. I expected the agents to churn and waste tokens mining data from the vault. The pairing of keyword and semantic search is the true power behind it. I can just describe what a note is about rather than what it says, and the agent finds it every time.

A folder of Markdown files, a sync container, and a tunnel gave every AI tool I use a shared memory that I can read myself. Total spend: a few pennies of embeddings, since everything else runs on subscriptions and hardware I already had. If your AI tools each keep their own little fiefdom, stand up your own stack!

OIDC Authentication with Keycloak (and Auth0, Okta, Azure AD)

Tue, 18 Aug 2026 03:52:19 +0000

If your team already runs an identity provider, the last thing you want is a second login system. You want your apps to trust the identity system you already have — whether that's Keycloak, Auth0, Okta, or Azure AD. OpenID Connect (OIDC) is the protocol that makes that possible, and a self-hosted WAF can speak it for you.

SafeLine supports OIDC out of the box. Instead of adding an OIDC client library to each app, you configure the identity provider once in the WAF, and it handles the redirect and the login gate in front of your applications. Here's the setup, straight from the docs.

What OIDC actually is

OpenID Connect is an identity layer built on top of OAuth 2.0. It lets a client application verify who a user is, based on the authentication result from an authorization server — and get back basic user information — without the client ever handling the user's credentials directly.

For a WAF, that's a clean fit: the WAF fronts your app, redirects unauthenticated visitors to your identity provider, and only lets approved users through.

Step 1: Prepare your OIDC provider

The docs walk through Keycloak as the reference example, since it's a common self-hosted choice. Here's how to get the parameters SafeLine needs:

Log in to the Keycloak admin console.
Select or create a Realm.
In the left menu, click Clients → Create to create a new client.
Fill in a Client ID — a unique identifier for the client.
In the Settings tab:
- Valid Redirect URIs — add the application's callback address, for example https://example.com/.safeline/auth/api/callback/oidc.
- Web Origins — add the application address, for example https://example.com.
Save, then switch to the Credentials tab and copy the Client Secret.

The key things to record:

Parameter	Example
OIDC Discovery URL	`https://{keycloak-host}/realms/{realm-name}`
Client ID	The client ID you created
Client Secret	The secret from the Credentials tab

The callback path is fixed: append /.safeline/auth/api/callback/oidc to your application URL.

Step 2: Configure SafeLine

In the SafeLine console, go to Auth → Settings → Login Configuration, find Third-Party Login, and select OIDC.

Fill in the form:

Field	What it's for
OIDC Server URL	Your provider's discovery URL. SafeLine appends `.well-known/openid-configuration` automatically
Client ID	From your OIDC provider
Client Secret	From your OIDC provider
Title Name	Shown on the blocking page — defaults to "Sign In - OIDC"
Use Proxy to Access	Check if your requests go through a proxy
Auto Merge Account	Automatically match incoming logins to existing accounts by email or phone number

Click Submit to save the binding.

Step 3: Enable OIDC on the application

Open Applications and pick the app you want to protect.
In that app's AUTH → Login Methods configuration, enable OIDC.
Save.

Once OIDC is enabled for an application:

A visitor opens the app and sees the OIDC login option.
Clicking it redirects them to your identity provider's login page.
After authenticating there, they're redirected back to SafeLine.
First-time users need to be approved by a SafeLine administrator before they can access the app.
Approved users get authorized and don't need another review for later visits; unapproved users are blocked.

Managing users

On AUTH → User Management you can view which users are linked, review new users, manage access permissions, and manually merge accounts.

FAQ

Can't redirect to the OIDC provider after integration?

Check that the OIDC discovery URL is correct and that it's reachable from a browser and returns valid JSON.

Callback fails after the user authenticates with the provider?

Confirm the callback address is configured correctly — protocol (http/https), domain, and path all need to match.

What scopes does SafeLine request by default?

openid, profile, and email (optional, used to link accounts), plus phone (optional, for account linking).

Do I need to write OIDC code in my app?

Not for the login gate itself. The WAF handles the redirect flow. You'd only add app code if the application needs the authenticated user's identity — via the auth callback flow.

Which providers are supported?

The docs name Keycloak, Auth0, Okta, and Azure AD, and note the list isn't limited to those — anything speaking standard OIDC should work.

If you already run Keycloak, Auth0, Okta, or Azure AD — are your internal apps currently trusting it, or are you maintaining a second login system?

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Add GitHub Login to Your Web App with a WAF

Tue, 18 Aug 2026 03:48:38 +0000

"Sign in with GitHub" is one of the first things developers reach for when an internal tool needs authentication. The usual route is a real engineering task: register a GitHub OAuth app, add an OAuth client library to your codebase, store the ClientID and ClientSecret, implement the callback handler, and manage sessions yourself.

There's a shorter path. If you front your web app with a self-hosted WAF that runs as a reverse proxy, you can let the WAF handle the entire GitHub OAuth flow — before a single request reaches your application code. SafeLine does exactly this. Here's the full walkthrough, straight from the docs.

A WAF already sits in front of your app, so every request passes through it. That makes it a natural place to gate access. Letting the WAF handle GitHub authentication means:

No OAuth code in your app. You don't add a client library, a callback route, or token storage.
One place to manage identity. Add or remove GitHub login across several apps from one console.
It works for anything. An internal dashboard, a legacy tool, or a static site can all get GitHub login the same way.

Step 1: Create the GitHub OAuth app

First you need a GitHub OAuth application to act as the identity source. This is done on GitHub's side, not SafeLine's.

From the GitHub documentation flow:

Go to GitHub and click your profile picture, then open Settings.
In the left sidebar, click Developer Settings.
Click OAuth Apps, then New OAuth App.
Fill in the application form:
- Application name — what users see on the authentication page.
- Homepage URL — your application's URL, for example https://a.com.
- Authorization callback URL — your homepage URL with /.safeline/auth/api/callback/github appended. For the example above: https://a.com/.safeline/auth/api/callback/github.

Once created, GitHub gives you the two values you'll need next: a ClientID and a ClientSecret.

The callback URL is the one place people get stuck. It's not arbitrary — it's always your Homepage URL plus the fixed path /.safeline/auth/api/callback/github.

Step 2: Configure SafeLine

Now move to the SafeLine console. Go to Auth → Settings → Login Configuration, find Third-Party Login, and select GitHub.

Fill in the configuration form:

Field	What it's for
ClientID	Your GitHub application ID
ClientSecret	Your GitHub application secret
Title Name	The name shown on the blocking page — defaults to "Sign In - GitHub"
Use Proxy to Access	Check this if your requests need to go through a proxy
Auto Merge Account	Automatically match incoming GitHub logins to existing accounts by email

Click Submit to save the binding.

Step 3: Enable GitHub on the application

Configuring the GitHub source isn't enough — you also have to switch it on for the specific app:

Open the Applications page and select the application you want to protect.
In that application's AUTH page, open the Login Methods settings.
Enable the GitHub option.
Save.

That's it. The app is now gated behind GitHub authentication.

What happens when a user tries to log in

Once the AUTH feature is enabled and GitHub is selected as the login method, the flow looks like this:

When someone visits the app, they're prompted to authenticate.
New users authenticate, then need to be reviewed and approved by a SafeLine administrator in the console before they can get in.
Approved users are authorized for the app and don't need another review — subsequent logins just work after authentication.
Unapproved users are blocked when they try to access the app.

That approval step is a useful default: it stops an open GitHub login from becoming a backdoor for anyone with a GitHub account.

On the AUTH → User Management page you can:

See whether users have linked their GitHub accounts.
Review new users for approval.
Manage access permissions per user.
Manually merge user accounts.

The "merge" option is handy when someone has been logging in one way and you want to fold their history into another account.

Optional: combine it with SSO

If you want users to authenticate just once and then reach several applications, GitHub login can feed into SSO:

Go to AUTH → Settings → SSO.
Enable the unified authentication feature.
Add applications to unified authentication.

After that, a user authenticates once — including through GitHub — and can access every application that's joined SSO.

FAQ

Not for the login itself. The WAF handles the OAuth redirect and gatekeeping. Your app only needs custom code if it has to know who logged in — for that you'd use the auth callback flow.

Why does a new GitHub user need admin approval?

It's the default safety behavior: first-time users trigger a review so an admin can confirm who gets access. After approval, the same user logs in without further review.

Yes. You configure the GitHub source once, then enable it on each application individually from that app's AUTH → Login Methods settings.

What if my traffic goes through a proxy?

Check the Use Proxy to Access option in the GitHub login configuration. That tells SafeLine to route its GitHub calls through a proxy.

Yes. SafeLine supports several login methods (account/password, OIDC, LDAP, and GitHub), and you can enable more than one for an application.

Have you wired up "Sign in with GitHub" the hard way before — and would you move that identity layer out of your code and into the WAF?

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Add Authentication and SSO to Any Web App Without Changing Code

Mon, 17 Aug 2026 16:03:48 +0000

Most people treat authentication as an application problem. If an internal dashboard, an admin panel, or a legacy tool doesn't have a login screen, the reflex is to open the codebase and start wiring up an auth library — OAuth clients, session management, user tables, password resets, the whole thing.

That's a lot of work to do once, and it's even worse when you have ten different apps that all need it.

There's a faster way: put the authentication layer in front of your apps instead of inside them. A self-hosted WAF that sits as a reverse proxy in front of your services can handle login for you — before a single request ever reaches your application code.

Here's how SafeLine does it, and how you can add both password protection and full SSO to any web app without touching its source.

Why do auth at the WAF layer?

A WAF is a reverse proxy: clients connect to the WAF first, the WAF filters and forwards traffic to your origin server. Because every request already flows through it, the WAF is a natural place to gate access.

That means:

No code changes. The app behind the WAF doesn't need an auth library, a user table, or any login UI of its own.
One place to manage. Instead of maintaining credentials in ten apps, you manage them in one console.
It works for anything. Legacy apps, static sites, internal tools, APIs — anything the WAF fronts can be protected.

SafeLine provides two authentication modes to cover different situations: Simple Auth and SSO.

Simple Auth vs SSO: two ways to gate access

SafeLine gives you two distinct modes, and the difference comes down to scope:

Simple Auth is application-specific. A user logs in to access that one application. If they move to a different app, they authenticate again.
SSO (Single Sign-On) is the opposite. A user logs in once and then accesses multiple related applications without repeated logins.

Think of Simple Auth as "lock this one door," and SSO as "issue one badge that opens every door you're allowed into."

Simple Auth: password-protect a single app

With Simple Auth turned on for an application, visitors must enter valid credentials before they can reach the app. Anyone who doesn't hold the credentials is blocked.

When you configure Simple Auth for an application, you pick a login method and set an Auth Callback URL.

The login method is how users prove who they are. SafeLine supports four:

Account + Password — a basic username/password login.
GitHub — sign in with a GitHub account.
OIDC — sign in through an OpenID Connect identity provider.
LDAP — sign in with an existing enterprise directory account.

The Auth Callback URL is what lets you pass the authenticated user's identity into your app, which I'll cover in detail below.

SSO is where this gets genuinely useful for teams. Once unified authentication is enabled, your users get a single sign-in entry point — an SSO center — and from there they can reach every application that has joined.

The docs describe three business scenarios where this fits naturally:

Enterprise application portal. Internal systems like OA, HR, and CRM each have their own auth today. With SSO, employees log in once and reach all of them, while IT centralizes access policy.
Modernizing legacy apps. Older apps often have no built-in auth, or a dated mechanism. SSO adds a modern authentication layer on top without modifying application code.
Zero trust. SSO is a core piece of a zero-trust architecture, giving every application access a consistent identity-verification and authorization path.

Enabling SSO

You enable SSO from the Auth-Settings page under the SSO tab. The configuration is a handful of fields:

Field	What it's for
Domain	The domain users visit to reach the unified authentication center (e.g. `home.in.example.cn`)
Port	An available port for the center
SSL	Optional, for HTTPS
Login Methods	The identity methods available (multiple can be enabled)
Force Enable TOTP	When on, every SSO user must use TOTP for two-factor authentication

Once enabled, users in the user list can access the SSO center by default.

Adding apps to SSO

To bring an application into SSO, go to Applications, click the app's AUTH button, and switch it over. Then you configure two fields:

Application Redirect URL — where the user is sent when they click the app in the SSO center.
Auth Callback URL — how authentication info is passed to the app server.

After that, when a user visits an application for the first time, they authenticate once. From then on, that one authentication covers every authorized application that has joined SSO.

A few details worth knowing from the SSO docs:

There is no limit on how many applications can join SSO.
You can edit an application's name and logo in the SSO center.
Users can only access applications they have permission for — joining SSO doesn't grant access to everything by default.
Logging out of the SSO center is not SLO (single logout) — that's not currently supported.

Whichever mode you use, the actual identity check is done by one of four methods.

Account + Password

The simplest option. You configure a username and password, and visitors enter it to get through. It's a good fit for a single admin or a small set of trusted users.

GitHub

SafeLine can let users sign in with their GitHub identity. You create a GitHub OAuth application to get a ClientID and ClientSecret, then fill those into SafeLine's third-party login configuration. The callback URL for GitHub follows the pattern:

https://your-app.com/.safeline/auth/api/callback/github

There's also an "Auto Merge Account" option to match incoming GitHub logins to existing accounts by email.

OIDC

For organizations that already run an identity provider, SafeLine speaks OpenID Connect. The docs call out Keycloak, Auth0, Okta, and Azure AD as supported providers.

Configuring it means pointing SafeLine at your provider's discovery URL (for Keycloak, something like https://{keycloak-host}/realms/{realm-name}) plus a Client ID and Client Secret. This is the method to reach for when you want your apps to trust the identity system you already have.

LDAP

For enterprise directories, SafeLine supports LDAP — including Microsoft Active Directory, OpenLDAP, and Apache Directory. Users log in with their existing enterprise accounts.

Configuration is the standard set of LDAP fields: a server URL (ldap://host:389 or ldaps://host:636 for SSL), a Bind DN, a Bind password, a user base DN, and a query condition. The query condition uses %s as a placeholder for the username, for example:

(&(objectClass=person)(uid=%s))

This is the one to use when you want a self-hosted gateway in front of an on-premise directory.

Passing the authenticated user into your app

Blocking unauthenticated traffic is only half the story. Often your app needs to know who just logged in. SafeLine handles this with a callback flow.

After a user authenticates, SafeLine redirects to your configured Auth Callback URL, appending a short-lived code:

http://example.com/application?code=123456&redirect_uri=original_user_access_address

Your application then exchanges that code for the user's identity by calling SafeLine's user-info endpoint:

GET http://safeline-console.com/.safeline/auth/api/user?code=123456
X-SLCE-API-TOKEN: safeline-api-token

The response gives you the user's id and username. Two things to note: the code can only be used once, and you'll find the API token in the console under Settings → Management.

After your app obtains the user info, it should cache the login state to decide whether the user is logged in for subsequent requests, then redirect to the redirect_uri. If retrieving the user info fails, your app should delete cookies with the sl_auth_session_ prefix and prompt the user to authenticate again.

Approvals and conditional auth

Two more knobs round out the picture, both under the app's AUTH advanced configuration:

Approval configuration. You can require that first-time users trigger an approval request after authenticating, which an admin must approve before the user gets in. Or you can let users access directly after authentication. The former is handy for sensitive internal tools where you want a human in the loop.
Conditional authentication. You can enable authentication (or skip it) only when specific conditions are met — for example, requiring auth for certain paths while letting other traffic pass.

Wrapping up

Authentication doesn't have to be a per-app engineering project. Because a self-hosted WAF already sits in front of your traffic, it's the natural place to gate access — and SafeLine turns that into a real feature set: per-app password protection, unified SSO across your apps, and four identity methods (password, GitHub, OIDC, LDAP) to choose from.

The result is that an internal dashboard, a legacy tool, or a static site can all get a proper login screen — and SSO — without a single line of application code changing.

If you want to try it yourself, the setup starts with a single command. The full authentication documentation is at docs.waf.chaitin.com.

FAQ

Does adding auth at the WAF layer slow down my app?

The check happens at the reverse-proxy layer before traffic reaches your origin, so your application itself isn't doing any extra work. The main cost is the one-time configuration.

Can I use SSO for both internal and public apps?

Yes. The mode is per-application, so you can put internal tools behind SSO while using Simple Auth or no auth on public apps, all from the same console.

Which identity provider should I pick?

If you already run Keycloak, Auth0, Okta, or Azure AD, OIDC is the natural fit. If you have an enterprise directory, use LDAP. GitHub is convenient for developer-facing tools, and Account + Password is fine for a small number of trusted users.

Do I have to modify my app to know who logged in?

Only if your app needs the user's identity. In that case you implement the callback flow (exchange the code for user info). If you just need to gate access, no code changes are required at all.

Does SafeLine's SSO support single logout?

Not currently. Logging out of the SSO center is not SLO.

Which of the four login methods — password, GitHub, OIDC, or LDAP — fits your current stack?

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Gnat, self-hosted analytics as a single Go binary, with a built-in MCP server

Fri, 14 Aug 2026 19:21:56 +0000

title: Gnat, self-hosted analytics as a single Go binary, with a built-in MCP server

tags: go, selfhosted, opensource, ai

A few months back I was crawling the web for a side project and came across an analytics platform's data that had exposed users' raw IPs. It wasn't malicious, just careless. But it stuck with me: most people using these tools have no idea their visitors' data is sitting around like that.

That's the moment that pushed me to build Gnat, a self-hosted analytics tool that doesn't cut corners on privacy, but also doesn't force you into a painful setup to get it.

No third party, no phoning home

Gnat runs entirely on infrastructure you control. There's no third party in the loop, no API calling home anywhere, and no data leaving your server. It's also completely free and open source, the whole thing is on GitHub.

One binary, zero bloat

Most self-hosted analytics tools make you choose: either something lightweight with barely any real analysis, or something with real analytical depth that also means Docker, a multi-service stack, and its own ops burden just to keep running.

Gnat is a single Go binary. No CGO, no Docker, no multi-service stack. The dashboard (HTML, CSS, JS) is compiled directly into the executable, so there's nothing else to install alongside it.

tar xzf gnat-vX.Y.Z-linux-amd64.tar.gz
cd gnat-vX.Y.Z-linux-amd64
./gnat

That's the whole install.

Real analytical depth

Despite being one binary, Gnat doesn't skimp on features:

Pageviews and custom events via a simple JSON POST (no per-language SDKs needed)
Funnels, cohorts, retention curves
Auto-discovered path analysis
SQLite by default, or Postgres/MySQL if that's how you already run infrastructure
CSV, JSON, jsonL, it's your data

Built for the agent era

The part I had the most fun building: Gnat ships with a native MCP server. Claude or any MCP-compatible agent can query your analytics directly, ask what changed, pull a report, whatever you need.

Where it's at

This is early, v0.1.0, and I'm actively building on it. Multi-site support, SSO/team access, and managed hosting are all on the roadmap but not built yet, the README is upfront about what's real today versus what's planned.

Gnat is licensed under AGPLv3, free to self-host and modify for any purpose, including commercially, but if you run a modified version as a service for others, the source has to stay open under the same terms.

Repo: https://github.com/var-raphael/Gnat

Feedback, issues, and contributions are very welcome. I'd love to hear what you think, especially if you've felt the same Docker-and-multi-service fatigue trying to self-host analytics.

Building What Was Missing: My Summer Finalizing MelaFreelance

Tue, 04 Aug 2026 16:42:59 +0000

I didn't set out to build the ultimate productivity platform, and I certainly didn't intend to disrupt the SaaS industry. I just wanted to stop paying monthly subscriptions for tools built for project managers instead of freelancers.

For years, I found myself stacking apps on top of each other—Asana for tasks, Everhour for time tracking—navigating complex interfaces only to use about ten percent of what I was actually paying for. In August 2025, out of pure frustration, I decided to sketch out a self-hosted alternative.

For a year, MelaFreelance was my silent partner, running in the background of my daily work. This August, during the quiet of the summer holidays, I finally added the missing pieces. The app is now complete—not because it has every feature in the world, but because it finally has exactly the ones I actually use.

Escaping the Subscription Bloat

When you work alone, you don't need team permissions, complex Gantt charts, or enterprise cloud syncing. You simply need to know what you are doing, how long it took, and whether you have been paid for it.

MelaFreelance is a quiet departure from the multi-tool chaos. It is a single, self-hosted space where the friction between tracking work and getting paid is entirely removed. Because it runs on my own server, I own the data. There is no cloud, no telemetry, and best of all, no monthly fees.

A Flow Built for Solo Work

The app is built on a modern stack (Laravel 12, Inertia 2, Vue 3, TypeScript, and Tailwind 4), but its philosophy is stubbornly simple. The hierarchy matches the reality of freelance work: Clients → Projects → Tasks.

Rather than forcing you to define rigid "project types" before you even start working, MelaFreelance adapts to your billing reality based solely on the data you enter:


Billing Mode	How It Handles Time & Money
Fixed-Price	Tracked time simply shows your effective hourly rate, but the flat fee dictates what you are owed.
Hourly	Every tracked minute is automatically multiplied by your set rate to calculate project earnings.
Non-Billable	For personal or pro-bono work, the financial UI elegantly drops away, leaving only your tracked hours.

The Little Details That Matter

The summer finalization wasn't about adding more features; it was about refining the daily experience and removing friction.

The Always-On Timer: A running timer sits in the app header on every page. I can navigate to my dashboard or reports without ever losing sight of the clock.
A Contextual Memory: If I start a new task, the previous one automatically stops and banks its time. If I pause, the timer remembers my place, offering a quick "Resume" button.
The Unified Task Canvas: Clicking a task opens a single workspace where I can edit notes, adjust the tracked time, and securely drag-and-drop private attachments (like PDFs or Figma links) that never leave my server.
A Realistic Payment Ledger: Freelance payments are rarely a simple yes/no checkbox. MelaFreelance lets me record deposits and part-payments as they arrive, automatically calculating what is still outstanding until the project is fully paid and sealed.

Yours If You Need It

I built MelaFreelance so I could finally cancel my SaaS subscriptions, stop looking at features I'll never use, and just get back to work.

With built-in dark mode, config-driven language support (English and Italian out of the box), and a frictionless setup using Laravel Sail or a local SQLite file, it has become exactly the tool I was missing.

"I tried every time tracker made for teams, so I built the missing one for freelancers."

It works beautifully for me. If you are tired of bloated software and want a tidy, private, and elegant space to track your hours and invoices, you are welcome to clone it and make it your own.

Check it out on Github

Mastering Self-Hosted Convex on Dokploy: A Complete Deployment Guide

Mon, 03 Aug 2026 07:41:58 +0000

So, you've decided to take control of your data and self-host Convex. It's a great choice but if you've tried pushing your functions to a local or private server, you might have run into cryptic errors about "Relative import paths" or "Missing modules."

The secret? You don't need custom deployment scripts. In fact, you shouldn't use them. The official Convex CLI is actually powerful enough to handle self-hosted deployments perfectly—if you know which buttons to press.

In this guide, I’ll show you exactly how to configure your project and deploy your functions like a pro.

1. Before You Start

Before we dive into the code, make sure you have the following ready:

Your Convex Instance: Whether you're using Dokploy, Docker, or a raw VPS, your backend should be up and running.
The Admin Key: You'll need the master key for your server.
- Tip: If you're using Dokploy, you can usually generate this by running ./generate_admin_key.sh inside your backend container's terminal.
The CLI: Make sure you have the latest version of Convex installed locally:
```
npm install convex
```

2. Preparing Your Project

For a smooth deployment, your convex/ folder needs to be a bit more "independent."

Step 1: Give Convex its own Identity

Create a package.json inside your convex/ directory. This ensures the CLI knows exactly which dependencies to bundle when it prepares your code for the server.

{
  "name": "my-convex-backend",
  "private": true,
  "type": "module",
  "dependencies": {
    "convex": "^1.16.0",
    "typescript": "^5.0.0"
  }
}

Step 2: Fix your Config

Ensure your convex/convex.config.ts is using the modern defineApp export. The server expects this structure to understand your app's layout.

import { defineApp } from "convex/server";

export default defineApp();

3. The Magic Environment Variables

The Convex CLI is "Cloud-first" by default, but we can tell it to target our own server by setting two specific environment variables.

Variable	What it does
`CONVEX_SELF_HOSTED_URL`	Points the CLI to your backend URL (e.g., `https://api.myapp.com`).
`CONVEX_SELF_HOSTED_ADMIN_KEY`	Your secret key. Crucial: It must include the `convex-self-hosted\|` prefix!

4. The Big Moment: Deploying

Now, let's push your code. We're going to use the official deploy command.

Run this from your root or convex directory:

CONVEX_SELF_HOSTED_URL="https://your-api-url.com" \
CONVEX_SELF_HOSTED_ADMIN_KEY="convex-self-hosted|your-key-here" \
npx convex deploy --typecheck disable

Why this works where other scripts fail:

When you use a custom fetch script to send files, you're just sending raw text. The server has no idea where convex/server is.

The CLI is smarter. It uses esbuild to "bundle" your code into a single, self-contained JavaScript package. It finds all your imports and bakes them right into the file so the server can run them instantly.

5. Pro Tip: Automate Everything

Don't type those long variables every time. Add a script to your convex/package.json:

"scripts": {
  "deploy": "CONVEX_SELF_HOSTED_URL=... CONVEX_SELF_HOSTED_ADMIN_KEY=... npx convex deploy --typecheck disable"
}

Now, all it takes is a simple:

npm run deploy

Troubleshooting common "Gotchas"

"Relative import path 'convex/server' not found"

If you see this, you likely bypassed the CLI. Always use npx convex deploy so the bundler can do its job!

"BadAdminKey"

Double-check your key. Most people forget the convex-self-hosted| prefix. Without it, the server will reject your request every time.

Missing `_generated` files in your frontend

Run npx convex codegen while your CONVEX_SELF_HOSTED_URL is set to update your local TypeScript types to match what you just deployed.

Happy hosting! Your Convex backend is now truly yours.

The Issues of Deploying Laravel on Dokploy: Database Connection Hell

Mon, 03 Aug 2026 07:41:12 +0000

If you’ve tried deploying a Laravel application on Dokploy (the self-hosted Heroku alternative built on Docker) and immediately ran into a wall of Database connection refused or SQLSTATE[HY000] [2002] errors, you are not alone.

It works perfectly on your local machine, but the moment it hits the server, it falls apart. Here is a real-world breakdown of the database connectivity issues we experienced, why they happened, and how to fix them.

1. The "Localhost" Trap (The `127.0.0.1` Connection Refused)

The Issue

On your local computer, you probably set your .env to:

DB_HOST=127.0.0.1
DB_PORT=3306

When you deploy this to Dokploy, your Laravel application crashes on start because it cannot connect to the database.

The Reason

Dokploy runs everything in isolated Docker Containers.
Inside a container, 127.0.0.1 or localhost refers to the Laravel container itself, not the host machine or your database container. Since there is no database running inside your Laravel code container, it refuses the connection.

The Solution

You must use Docker's internal networking.

If your database is created inside Dokploy, Dokploy assigns it a specific network service name (e.g. dokploy-db-mysql or the service name you typed in the database creation wizard).
Change your host in the Dokploy Environment Variables UI to match that service name:
```
DB_HOST=dokploy-db-mysql  # Use Dokploy's internal container name
```

2. The Config Caching Nightmare (Why changing Env Variables in the UI did nothing)

The Issue

You realized the host was wrong, went to the Dokploy dashboard, updated the DB_HOST environment variable to the correct container hostname, saved, and redeployed.
Yet, the app still threw the old connection error looking for 127.0.0.1. You checked the container logs, confirmed the new environment variables were set, but Laravel simply ignored them.

The Reason

This happens if you run configuration caching in your Dockerfile during the build step:

RUN php artisan config:cache

When Laravel builds your container, it runs config:cache and bakes whatever .env values exist at build-time directly into a static cache file (bootstrap/cache/config.php).
At runtime, Laravel completely ignores your Dokploy UI environment variables and loads the baked-in values instead.

The Solution

Never cache your configuration during the Docker build stage if you plan to change environment variables dynamically.

Remove RUN php artisan config:cache from your build steps.
If you want caching for speed in production, clear it on boot by running php artisan config:clear or php artisan optimize:clear inside your container's startup command / entrypoint script.

3. The Race Condition (Migrations crashing the build)

The Issue

You configured your Docker container to automatically run migrations on deployment:

php artisan migrate --force

But your deployment failed during this step because the database connection timed out or was refused, even though all credentials were 100% correct.

The Reason

When Dokploy restarts or provisions your stack, it starts both the Laravel container and the MySQL/PostgreSQL container simultaneously.
Laravel boots up in milliseconds and immediately tries to run migrations. However, MySQL is still executing its slow initial setup scripts, checking schemas, and opening sockets. The database container isn't ready to receive queries yet, so Laravel's migration command crashes, failing the entire Dokploy deployment.

The Solution

You need to make Laravel "wait" for the database to boot. Add a small bash loop to your entrypoint script (entrypoint.sh) that pings the database port before running migrations:

echo "Waiting for MySQL to boot..."
until nc -z -v -w30 $DB_HOST $DB_PORT; do
  echo "MySQL is not ready yet. Retrying in 2 seconds..."
  sleep 2
done
echo "MySQL is up! Running migrations..."
php artisan migrate --force

4. Port Mapping Confusion (Internal vs. External Ports)

The Issue

Mapping your Dokploy MySQL database port to 3306 (or 3307) externally so you could connect via TablePlus/DBeaver from your laptop, but when configuring your Laravel .env inside Dokploy, you weren't sure which port to use.

The Reason

Docker has two layers of ports:

Internal Port: The port the service listens to inside the Docker private network (always 3306 for MySQL).
External/Exposed Port: The port mapped to the public server IP so you can connect from the outside world (e.g., mapping host 3307 to container 3306).

Inside Dokploy, your Laravel app and your MySQL container share the same private network. Therefore, they communicate internally.

The Solution

For Laravel (.env on Dokploy): Always use the internal port (DB_PORT=3306).
For TablePlus/DBeaver (External laptop): Use the exposed host port (3307) and the public server IP.

Summary Checklist for Dokploy deployments

Set DB_HOST to the internal Docker container/service name, not 127.0.0.1.
Set DB_PORT to the internal port (3306 for MySQL), not the exposed host port.
Avoid running php artisan config:cache during Docker build time.
Implement a wait-for-it check in your startup script so migrations don't run before MySQL is fully booted.

The Missing Freelance Time Tracker

Sat, 01 Aug 2026 10:02:43 +0000

The Missing Freelance Time Tracker

It has a name now: MelaFreelance. Here's what it is, and why it's yours — not mine.

In the last piece I explained the itch: every time tracker I tried was built for teams, and I'm one person with a client, a project, and a clock. So I stopped renting other people's tools and built the small one I actually needed.

This is that tool. It's called MelaFreelance, and this is what it turned out to be.

Built one summer, polished the next

The first commit landed in August 2025, in the slow, warm gap where the client emails thin out and there's finally room to make the thing you keep meaning to make. It wasn't pretty. It had no options, no settings, no polish — just the raw mechanics I needed to answer who owes me what. And then I did the most honest test there is: I used it. Every day, for a straight year, exactly as it was.

A year of real use is a brutally good editor. It tells you which features you invented and never touch, and which rough edges you step over so often you stopped noticing. Nothing survives that a design doc would have kept, and nothing gets cut that you actually reach for.

So here we are, another August, the same quiet slice of the calendar — and this time the work isn't building it, it's finishing it. The polish it earned by proving, over twelve months, that it deserved to exist.

There's a second reason the timing is right. Lately I've been deep in a much heavier project — S-MoE, a sparse mixture-of-experts build that lives in exactly the kind of complexity you can't hold in your head on a hot afternoon. After enough of that, coming back to MelaFreelance feels like stepping out of a machine room into the sun. Small surface, clear edges, an obvious right answer for every question. Simple work — but not unimportant work. Sometimes the most useful thing you can build is the one you can finish.

It's yours, not mine

Here's the decision that shapes everything else: MelaFreelance isn't a service you sign up for. It's a thing you run.

There's no account on my server, no subscription, no "free tier" quietly counting your clients until it asks for a card. You clone it, you point it at your own database, and it's yours — data and all. If I vanish tomorrow, your tool keeps working, because it was never on a server I control.

That's not an accident, it's the whole philosophy. The tools that broke me in the first place all had one thing in common: my data lived in their product, on their terms, one pricing-page change away from held hostage. A tracker for freelancers should be the one piece of software a freelancer never has to worry about losing.

So it's single-user by default — no seats, no invites, no "workspace." One person clones it, runs one command to create their account, and starts working. Everything about it assumes you are the only human who will ever log in, because for me, that's the truth.

The timer that's always there

The most-used thing in a time tracker is the start/stop button, so I refused to bury it.

In MelaFreelance the running timer isn't a widget you navigate to — it lives in the app's chrome, on every page. Wherever you are, you can see what's ticking and stop it. And there's exactly one rule the app enforces for you, quietly: you can only run one timer at a time. Start a task while another is running and the old one banks its minutes and stops on its own. A freelancer works one thing at a time; the tool should never let two clocks claim the same minute.

When you stop, the bar doesn't just disappear. It remembers the last thing you were on — "was I still on the Rossi homepage?" — with a one-click Resume, until you dismiss it. Small thing. I use it twenty times a day.

The number that matters

Open the app and the first thing it tells you is the number I actually came for: what am I owed, and what's still outstanding?

Not tracked hours dressed up as money. Not an invoice-count vanity stat. Just: across every project, how much has been paid, and how much is still out there. Because payments in MelaFreelance are a ledger, not a checkbox — a deposit, a milestone, a final balance — "paid" and "outstanding" are simply the arithmetic on that ledger. And the arithmetic is done once, on the backend, in whole cents, so the number on your dashboard is the number, every time. No rounding drift, no two screens disagreeing.

Money can be windowed — received this month — because every payment carries a date. Hours are all-time, on purpose: a task holds one running total, not a pile of dated entries I'd have to maintain. That asymmetry is a feature. It's the difference between a tool that answers your question and a tool that invents new ones to justify itself.

Still small on purpose

I've added things since launch — a gentle nudge to mark a project done when its last task finishes, a proper time picker, non-billable projects for the client called "Myself." But the rule hasn't changed: nothing ships unless I hit the need for it in my own week.

That's the luxury of building for exactly one user. There's no roadmap to defend, no enterprise deal bending the design, no feature added to win a comparison chart. When something annoys me, I fix it. When something's missing, I add it. When it's fine, I leave it alone — which is most of the time, and exactly the point.

MelaFreelance is free, it's open, and it's built to be cloned. If you're a freelancer who's tired of renting the basics, you don't have to wait for me to build your features. You can take it and make it the tool you needed all along.

That was always the missing one. Built in one summer, quietly proven through a year of real work, and finished in the next. If a tool can earn that, it's earned a place on your machine too.

MelaFreelance — built by a freelancer, for freelancers. Clone it, own it, get back to the work.

Coder Legion - Recent posts tagged selfhosted

Why I Protect Only Some Homelab Services With a WAF

Which self-hosted services should sit behind a WAF?

Is a small homelab host enough?

What do I enter for one public site?

How can I verify that a probe was blocked?

Does this replace private networking or app login?

How to Choose a WAF for a Homelab Before You Publish Anything

Sort services before you sort controls

Match documented threats to homelab exposure

Pick controls by failure mode

Confirm the host can carry the proxy

Prove the path with the documented tests

Does a homelab WAF cover every self-hosted service?

Which homelab host facts are actually required?

Should I enable every challenge on day one?

How do I know the WAF, not another hop, blocked the request?

What should I leave off this checklist?

Open Source vs. Proprietary: Why We Built Parts of AnimeArray with Open-Source Tools

What "owning it" actually got us

The part nobody wants to hear

Where we deliberately chose proprietary

The four questions we ask

What this actually means for the people who use the site

If you're starting something similar

Reverse Proxy or Transparent WAF? A Checklist for Web Teams

Reverse Proxy or Transparent WAF? A Checklist for Web Teams

FAQ

Does SafeLine support both rule-based and semantic protection?

Should I test changes before production?

Where can I check current Pro pricing?

Is the sale renewable at the same price?

Reverse Proxy or Transparent WAF? A Checklist for Web Teams

Reverse Proxy or Transparent WAF? A Checklist for Web Teams

FAQ

Does SafeLine support both rule-based and semantic protection?

Should I test changes before production?

Where can I check current Pro pricing?

Is the sale renewable at the same price?

Reverse Proxy WAF vs Transparent Bridge: A Deployment Decision

Reverse Proxy WAF vs Transparent Bridge: A Deployment Decision

Reverse proxy trade-offs

Transparent designs

FAQ

Does SafeLine support both rule-based and semantic protection?

Should I test changes before production?

Where can I check current Pro pricing?

Is the sale renewable at the same price?

SafeLine’s 700K Install Sale Is Live: Save up to 35% on Pro

SafeLine’s 700K Install Sale Is Live: Save up to 35% on Pro

What Pro adds

Sale plans

Before you buy

SafeLine’s 700K Install Sale Is Live: Save up to 35% on Pro

What Pro adds

Sale plans

Before you buy

Cloud WAF or Self-Hosted WAF? Four Questions for Teams

Cloud WAF or Self-Hosted WAF? Four Questions for Teams

Traffic and data path

Ownership and rollout

What SafeLine adds

FAQ

Does a WAF replace every other security control?

Is reverse proxy placement important?

Should I enable every protection immediately?

Where can I verify the product details?

Cloud WAF vs Self-Hosted WAF: A Deployment Decision Guide

Cloud WAF vs Self-Hosted WAF: A Deployment Decision Guide

Cloud advantages

Self-hosted advantages

What SafeLine adds

FAQ

Does a WAF replace every other security control?

Is reverse proxy placement important?

Should I enable every protection immediately?

Where can I verify the product details?

SafeLine WAF vs Imperva: Self-Hosted WAF vs Enterprise Cloud Protection

SafeLine WAF vs Imperva: Self-Hosted WAF vs Enterprise Cloud Protection

What each one is