Coder Legion - Recent posts tagged self-hosted

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

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

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

When a larger organization evaluates a WAF, the conversation quickly moves past "does it block attacks?" to "who controls it, and what does it cost?" Here's how an enterprise cloud WAF compares to a self-hosted one on those two axes.

Control

A self-hosted WAF (like SafeLine) puts configuration in your hands. You set the rules, you see the raw traffic, and the data stays on your infrastructure. For teams with strict data-residency or compliance needs, that control is the whole point.

An enterprise cloud WAF (like Imperva) centralizes control with the vendor. You get a polished console and bundled services (CDN, DDoS, bot management), but you operate within their model and route traffic through their edge.

Cost

Self-hosted: the Community Edition is free for up to 10 apps at 800 QPS. Larger needs use paid tiers, but there's no per-seat or per-property enterprise premium.
Enterprise cloud: priced as a subscription sized to your traffic and feature set, typically with a contract and onboarding.

For a handful of sites, self-hosted is effectively free to start. For a global estate with compliance and SLA requirements, the managed platform's bundled services can justify the spend.

Where each fits

	Self-hosted	Enterprise cloud
Best for	Small teams, cost-sensitive, control-focused	Large orgs, compliance, SLA needs
Cost model	Free tier + optional paid tiers	Enterprise subscription
Data	On your servers	Through vendor edge
Extras	Dashboard, stats	CDN, DDoS, bot mgmt

Getting started self-hosted

If you want to see the control model for yourself, install SafeLine on a server you already have:

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 your traffic is filtered — no contract, no DNS change.

FAQ

Is self-hosted "enterprise-grade"?

The detection engine is production-grade semantic analysis with low false positives, used at scale. The free tier is sized for ~10 apps; paid tiers cover more.

Do I lose the CDN with self-hosted?

A self-hosted WAF focuses on the application layer. Pair it with whatever CDN you already use.

Which is faster to deploy?

Self-hosted: one command and a console. Enterprise cloud: onboarding plus routing setup.

Ready to give SafeLine a try?

Appliance WAF vs Container WAF: The Deployment Trade-off

Sat, 10 Oct 2026 10:27:41 +0000

Appliance WAF vs Container WAF: The Deployment Trade-off

Not all WAFs deploy the same way. Some ship as dedicated hardware or virtual appliances; others run as a lightweight container on a server you already own. The difference changes your cost, your footprint, and how fast you can get protected.

The appliance model

An appliance-based WAF (like Barracuda WAF) is typically delivered as a hardware box, a virtual appliance, or a cloud instance. It's often purchased with a support contract and managed through the vendor's console. The upside is vendor backing; the downside is heavier provisioning and dedicated resources.

The container model

A container-based WAF (like SafeLine) runs as a reverse proxy on your existing server. One install command, and it's filtering traffic. No dedicated hardware, no separate instance to babysit.

Comparing the trade-offs

	Appliance WAF	Container WAF
Provisioning	Hardware/virtual appliance + setup	One container on existing server
Footprint	Dedicated resources	Lightweight, shared host
Support model	Vendor contract	Community + paid tiers
Cost	License + often support	Free Community Edition; paid tiers
Time to protect	Longer	Minutes

Which should you choose?

If your environment mandates an approved appliance with vendor SLAs, that's a procurement decision a container WAF doesn't aim to replace. For most teams, a container WAF is enough and dramatically cheaper to run.

Spin up SafeLine on a server you already have:

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 your traffic is filtered — no appliance to provision.

FAQ

Does SafeLine need dedicated hardware?

No. It runs as a container on a server you already operate.

Can a container WAF block the same attacks as an appliance?

For application-layer threats (SQLi, XSS, bots), yes — both filter HTTP traffic; the delivery model is what differs.

Which is faster to deploy?

Container: one command and a console. Appliance: provisioning plus configuration.

Ready to give SafeLine a try?

Appliance WAF vs Container WAF: The Deployment Trade-off

Sat, 10 Oct 2026 06:09:10 +0000

Appliance WAF vs Container WAF: The Deployment Trade-off

The appliance model

The container model

A container-based WAF (like SafeLine) runs as a reverse proxy on your existing server. One install command, and it's filtering traffic. No dedicated hardware, no separate instance to babysit.

Comparing the trade-offs

	Appliance WAF	Container WAF
Provisioning	Hardware/virtual appliance + setup	One container on existing server
Footprint	Dedicated resources	Lightweight, shared host
Support model	Vendor contract	Community + paid tiers
Cost	License + often support	Free Community Edition; paid tiers
Time to protect	Longer	Minutes

Which should you choose?

Spin up SafeLine on a server you already have:

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 your traffic is filtered — no appliance to provision.

FAQ

Does SafeLine need dedicated hardware?

No. It runs as a container on a server you already operate.

Can a container WAF block the same attacks as an appliance?

For application-layer threats (SQLi, XSS, bots), yes — both filter HTTP traffic; the delivery model is what differs.

Which is faster to deploy?

Container: one command and a console. Appliance: provisioning plus configuration.

Ready to give SafeLine a try?

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Sat, 10 Oct 2026 06:08:23 +0000

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Control

Cost

Self-hosted: the Community Edition is free for up to 10 apps at 800 QPS. Larger needs use paid tiers, but there's no per-seat or per-property enterprise premium.
Enterprise cloud: priced as a subscription sized to your traffic and feature set, typically with a contract and onboarding.

For a handful of sites, self-hosted is effectively free to start. For a global estate with compliance and SLA requirements, the managed platform's bundled services can justify the spend.

Where each fits

	Self-hosted	Enterprise cloud
Best for	Small teams, cost-sensitive, control-focused	Large orgs, compliance, SLA needs
Cost model	Free tier + optional paid tiers	Enterprise subscription
Data	On your servers	Through vendor edge
Extras	Dashboard, stats	CDN, DDoS, bot mgmt

Getting started self-hosted

If you want to see the control model for yourself, install SafeLine on a server you already have:

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 your traffic is filtered — no contract, no DNS change.

FAQ

Is self-hosted "enterprise-grade"?

The detection engine is production-grade semantic analysis with low false positives, used at scale. The free tier is sized for ~10 apps; paid tiers cover more.

Do I lose the CDN with self-hosted?

A self-hosted WAF focuses on the application layer. Pair it with whatever CDN you already use.

Which is faster to deploy?

Self-hosted: one command and a console. Enterprise cloud: onboarding plus routing setup.

Ready to give SafeLine a try?

WAF 101: What Actually Happens When a Request Hits Your Firewall

Sat, 10 Oct 2026 04:24:57 +0000

WAF 101: What Actually Happens When a Request Hits Your Firewall

You've been told a WAF sits in front of your app and blocks bad traffic. But what actually happens, step by step, when a single HTTP request arrives? Here's the lifecycle — no marketing, just the mechanics.

1. The request hits the proxy

A WAF runs as a reverse proxy. Every request to your app lands at the WAF first, not your application. The WAF is the gatekeeper; your app only ever sees what the gatekeeper lets through.

2. It parses the request

The WAF reads the pieces that matter: the URL, the headers, the cookies, and the request body. A network firewall only looks at IPs and ports; a WAF understands HTTP, so it can see the content of the request.

3. It makes a decision

For each request, the WAF decides allow, block, or challenge:

Allow — looks like a normal request, forward to your app.
Block — matches an attack pattern (SQL injection, XSS payload, malicious bot), drop it.
Challenge — suspicious but not certain, e.g., a CAPTCHA or JavaScript check.

4. Two ways it detects attacks

Signature-based: matches known attack strings, like an antivirus. Needs constant updating, and novel attacks slip through.
Semantic analysis: understands what the 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.

5. Clean traffic moves on

Anything the WAF allows is forwarded to your application. Anything blocked never reaches your code — so the attack surface your app has to defend shrinks to near zero.

Why placement matters

A self-hosted WAF like SafeLine runs on your own server as a reverse proxy. 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 every request flows through the gatekeeper first — no third party in the path.

FAQ

Does a WAF replace my network firewall?

No. They handle different layers. The network firewall governs connections; the WAF understands HTTP.

Will it slow my site?

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 patching, rate limiting, and (if needed) a CDN for broader coverage.

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

Self-Hosted vs Managed WAF: Which Deployment Fits Your Team?

Sat, 10 Oct 2026 03:59:58 +0000

Self-Hosted vs Managed WAF: Which Deployment Fits Your Team?

Picking a WAF usually comes down to one question: do you want to run the security infrastructure yourself, or pay someone to run it for you? That single decision shapes your cost, your control, and how much operational work lands on your plate.

Two deployment models

Self-hosted (e.g., SafeLine). You install the WAF on your own server — one command — and it runs as a reverse proxy in front of your app. Your traffic never leaves your network, and you decide the config.

Managed cloud (e.g., Sucuri). The vendor runs the WAF in their own network. You point your DNS at them, and they filter traffic before it reaches you. Someone else operates the infrastructure.

What you actually give up or keep

	Self-hosted	Managed cloud
Where traffic flows	Your server only	Through the vendor's cloud
Upfront cost	Free tier available	Recurring subscription
Operational work	You patch and monitor	Vendor handles uptime
Control over config	Full	Limited to their console
Data residency	Stays with you	On the vendor's servers

How to decide

Choose self-hosted if you want predictable cost, full control, and to keep request data on your own infrastructure. SafeLine's free Community Edition covers up to 10 apps at 800 QPS and installs in one line:
```
bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
```
Then open https://<your-server-ip>:9443 and point it at your app. No DNS change required.
Choose managed cloud if you'd rather offload operations entirely and you also want extras like malware cleanup and a CDN bundled in. The trade-off is a monthly fee and routing traffic through a third party.

The bottom line

Neither is "better" in the abstract — they optimize for different things. Self-hosted wins on cost and control; managed wins on convenience. If you're a small team that wants strong protection without a sales call, starting self-hosted is usually the faster, cheaper path.

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

SafeLine WAF vs Cloudflare WAF: Which Should You Put in Front of Your App?

Thu, 10 Sep 2026 10:52:28 +0000

SafeLine WAF vs Cloudflare WAF: Which Should You Put in Front of Your App?

When you start shopping for a web application firewall, Cloudflare is usually the
first name that comes up. It is a mature, globally distributed service. But "first name" is not
the same as "best fit", especially if you run your own infrastructure and care about data
residency, cost at scale, or simply not handing your traffic to a third party.

What Cloudflare WAF gives you

Cloudflare is a reverse-proxy SaaS: traffic is routed through Cloudflare's edge before reaching
your origin. You get a large global network, DDoS absorption, a mature rules marketplace, and a
free tier that is genuinely useful. For many sites that is enough.

Where a self-hosted option fits better

SafeLine WAF is a self-hosted WAF by Chaitin. Instead of sending traffic to someone else's
cloud, you run it as a container in front of your own stack. That matters when:

You must keep traffic inside your own network (compliance, latency, data residency).
You want predictable cost instead of per-site or per-request pricing that grows with traffic.
You prefer to own the control plane rather than depend on a vendor's dashboard.

Detection approach

Cloudflare leans on a huge signature/rules ecosystem plus ML at the edge. SafeLine uses a
semantic-analysis engine that models the intent of a request rather than only matching
known attack strings. In practice that tends to catch variant and obfuscated payloads (SQLi,
XSS, command injection) with fewer hand-tuned rules.

Trade-offs

Cloudflare wins on out-of-the-box global DDoS and zero-infra. SafeLine wins on control, privacy,
and a free self-hosted Community Edition. If you already run servers, adding one container is a
small operational step for a lot of control back.

FAQ

Do I need to change my DNS to use SafeLine?

No. SafeLine works as a reverse proxy you point your upstream at; you control routing yourself.

Is SafeLine really free?

The Community Edition is free and covers 10 applications at 800 QPS, which is enough for most
small and mid-size deployments.

Can SafeLine replace Cloudflare entirely?

For application-layer protection in front of your own apps, yes. For global anycast DDoS you may
still want a network-level service underneath.

Wrap Up

If you want a self-hosted WAF you fully control, SafeLine is worth a look. It sits in
front of your existing stack as a container, uses a semantic-analysis engine to catch SQL
injection, XSS, and bot abuse with very low false positives, and the Community Edition is
free.

Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Live demo: https://demo.waf.chaitin.com:9443/statistics

Deploy it in minutes:

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

How to Size a Server for Local AI Agents

Sun, 30 Aug 2026 17:52:29 +0000

Most of us end up speccing a box for local models because an API bill or a privacy requirement made the decision for us, not because we wanted a hardware project. This is the sizing math I keep coming back to, aimed at developers who want a working setup rather than a benchmark chase.

Start With VRAM, Everything Else Follows

The baseline is roughly 2 GB of VRAM per billion parameters at FP16. A 7B model wants about 14 GB at full precision, about 7 GB at Q8, and roughly 3.5 GB at Q4 with some quality trade-off. That single ratio decides which models you can run at all.

On consumer cards, a used RTX 3090 at 24 GB is still the value pick, the 4090 matches it at 24 GB with more speed, and the 5090 moves the ceiling to 32 GB. Two 3090s give you 48 GB combined, which is enough for a 70B model at Q4, but multi-GPU adds power, cooling, and PCIe lane problems. For a single developer running agents, one high-VRAM card is simpler and more reliable than splitting across two.

CPU And RAM Are The Quiet Bottlenecks

For inference on one model, a modern 8 core CPU is plenty. The moment you host several agents at once or do any training, step up to 12 or more cores so tokenization and request routing do not stall behind each other.

System RAM should be about double your total VRAM. A 24 GB card wants 64 GB as a practical minimum, and a 70B model with CPU offloading can need 96 to 128 GB because the offloaded layers live in system memory. DDR5 over DDR4 for the bandwidth, and ECC if the box runs continuously.

Storage Decides How Fast You Iterate

A quantized 7B model is 4 to 8 GB on disk and a 70B is 35 to 70 GB, so a model collection reaches terabyte scale quickly. Sequential read speed is what you feel day to day: a PCIe 4.0 NVMe at 5,000 to 7,000 MB/s loads a 30 GB model in about 5 seconds, while a SATA SSD at 550 MB/s takes nearly a minute for the same file.

A 1 TB NVMe for the OS and active models plus a 2 TB secondary drive for archives and datasets covers most single-machine setups. The full AI server requirements guide breaks the same decisions down component by component if you want the longer version.

Pick A Tier, Not A Dream Build

Under $500 buys a used office PC with 32 GB of DDR4 and an 8 GB card, which runs 7B models at Q4 around 5 to 15 tokens per second. That is genuinely usable for a personal assistant or a single agent.

Between $500 and $2,000, a 3060 12 GB or a used 3090 with 64 GB of DDR5 and a 1 TB NVMe gives 20 to 40 tokens per second on 13B models and room for several concurrent agents. Above $2,000, a 4090 or 5090 with 128 GB of RAM handles most open weight models at useful quantization levels.

The Software Side Is Mostly Settled

Ubuntu Server LTS is the path of least resistance because that is what the frameworks are tested against. CUDA 12.x covers every NVIDIA card from the 30-series onward, and for serving you pick by workload: vLLM for batched throughput, llama.cpp for the widest hardware compatibility, Ollama when you want the simplest setup. Docker with the NVIDIA Container Toolkit keeps the CUDA versions from fighting each other.

Takeaway

Get the VRAM number right first, give the machine twice that in system RAM, put the models on NVMe, and the rest of the build stops being interesting in a good way. Almost every disappointing local setup I have seen failed on one of those three numbers rather than on the model choice.

n8n For AI Agent Workflows: Check The Execution Model Before The Node Catalog

Thu, 27 Aug 2026 06:55:08 +0000

Most of us have written the same glue between an LLM call, a vector store and half a dozen APIs more than once, and the pitch for any visual layer is that you stop rewriting it. If you are weighing that against another bespoke script, the first thing to check is not the node catalog, it is how the platform counts your work, because that number is what decides the bill at volume.

What n8n Is Underneath The Canvas

n8n is an open source automation platform built on a node based editor, where each node is an action: an API call, a transform, a message, a model inference. Workflows fire on webhooks, schedules, database changes or chat messages.

What separates it from the simpler tools is that you can drop into inline JavaScript or Python at any point in the graph. There are over 500 prebuilt integrations, and for anything without a node the HTTP Request node takes a raw curl command.

The Community Edition runs under a fair-code license. You self host it for free with unlimited executions, unlimited workflows and the full integration catalog. SSO, LDAP and audit logs are the parts behind a paid license.

The AI Agent Node Binds Other Nodes As Tools

The AI subsystem is built on LangChain, exposed as more than 70 visual nodes covering models, memory, chains, retrievers, vector stores, embeddings and output parsers.

The piece worth understanding is the AI Agent node. It is not a prompt template, it is a ReAct or OpenAI Functions agent with tool bindings, memory and an iterative reasoning loop. Any other n8n node can be bound as a tool, so the agent can query Postgres, hit an internal API or update a sheet as part of its own reasoning, and it picks which to call from context instead of following a path you hardcoded.

Model nodes cover OpenAI, Anthropic, Google, Mistral, Cohere and local models through Ollama. Swapping providers means swapping one node, the rest of the graph stays where it is.

Where The Execution Model Changes The Math

One execution is one complete workflow run, no matter how many nodes are in it. A 20 node workflow that runs once is one execution. Only successful runs count, so failed and test runs are free.

Put that next to per-task metering and the gap opens fast. Ten thousand runs of a ten step workflow is ten thousand executions here, and one hundred thousand tasks on a platform that bills each step. n8n Cloud Pro is 60 euros a month for ten thousand executions. Self hosting the same load costs a VPS, roughly four to seven dollars a month, because the execution ceiling disappears entirely. The full breakdown of the AI nodes, RAG setup and pricing tiers walks through where each path stops making sense.

Running The Whole Stack Locally

The Self-Hosted AI Starter Kit is a Docker Compose template that bundles n8n with Ollama for local models, Qdrant for vectors and PostgreSQL for data and conversation memory, in one command.

There are profiles for NVIDIA and AMD GPUs, a CPU only profile for testing, and on a Mac you run Ollama natively and point the containerized n8n at it. It is Apache 2.0, separate from the fair-code license on n8n itself, so there is nothing to negotiate around commercial use.

That gets you RAG pipelines, agents with persistent memory and local document processing without a single call leaving the machine, which is the part that matters if you are working under data sovereignty rules.

The Takeaway

Node count is the least interesting number on the page. What you actually want to know before committing a workflow to production is what the platform counts as one unit of work, when that count resets, and whether removing the ceiling is a matter of running it yourself. On n8n all three answers are good, and that is the reason it keeps showing up in agent stacks that started out as scripts.

The Five Layers Of A Self-Hosted AI Stack

Sat, 22 Aug 2026 04:01:24 +0000

Plenty of the self-hosting threads here stop at the point where a model finally answers on localhost. This is a map of everything that sits around that, because inference turns out to be the easy layer.

The Five Layers

Inference loads model weights and generates tokens. Ollama when you want it to just work, vLLM for production throughput, llama.cpp when you are squeezing an underpowered box.

Embeddings turn text into vectors and search them. Qdrant, ChromaDB or pgvector, paired with an embedding model like nomic-embed-text or BGE. This is the layer that lets a model answer questions about documents it never saw in training.

Memory gives agents knowledge that survives the session. Conversation history, session state, long term facts, knowledge graphs. Redis and Postgres do most of the real work here.

Tools connect the model to everything outside itself. An LLM only emits text, so reading files, calling APIs, querying databases and running code all live at this layer. MCP servers and function calling frameworks sit here.

Orchestration decides which model runs, when to retrieve context, which tool to call and how multiple agents hand off. LangGraph, n8n, Dify, or your own code. Without it you have five services. With it you have an agent.

Where Setups Actually Break

Most stalled self-hosting projects have layers one and two and nothing else, and the symptoms are consistent. The assistant is impressive on a single question and useless across a week, because there is no memory layer. Every component works alone and nothing composes, because there is no orchestration. Neither failure looks like a model problem, so people go shopping for a bigger model instead of the missing layer.

The Cost Math Has A Floor

Self-hosting is not automatically cheaper. A consumer GPU like a 12 GB RTX 3060 runs about 300 to 400 dollars and handles a 7B model comfortably, with maybe 10 to 20 dollars a month in electricity. Against cloud pricing of roughly 0.15 to 0.60 dollars per million input tokens, 100,000 tokens a day costs 15 to 60 dollars a month, so the card pays for itself somewhere between six months and two years.

Below that volume an API is genuinely cheaper and you should use one. Above it, and especially where the data cannot leave your hardware for compliance reasons, the fixed cost structure wins and keeps winning as volume grows. Rented GPU instances sit in between at 0.50 to 2.00 dollars an hour, which is fine for bursts and expensive for always-on.

Starting Order

Start with inference so you have something that responds, add embeddings when you need it to know your own documents, then memory, then tools, then orchestration. Adding them in that order means each layer has something to plug into, and you can stop at whatever depth your use case actually needs.

If you want the long version, the full five layer breakdown covers each layer's tooling options, a couple of ready-made stack combinations, and the cost comparison in more detail.

5 Docker Security Mistakes That Leave Your Applications Exposed

Mon, 27 Jul 2026 09:27:01 +0000

5 Docker Security Mistakes That Leave Your Applications Exposed

Docker · Security · DevOps · Self-Hosted · Web Security

Docker has become the default way to deploy modern applications. Whether you're running a personal project, an internal dashboard, or a production service, spinning up a container takes only a few minutes.

The problem is that many developers unconsciously assume a containerized application is also a secure application.

It isn't.

Docker provides process isolation and simplifies deployment, but it doesn't protect your application from HTTP-based attacks, automated scanners, credential stuffing, or malicious bots. Those problems exist at the application layer, long after packets have reached your server.

Over the past few years, I've reviewed dozens of Docker deployments—from personal side projects to production systems maintained by small engineering teams. Although every stack looks different, the same security issues appear again and again.

This article covers five of the most common mistakes, why they matter, and how you can improve your security posture without dramatically increasing operational complexity.

1. Assuming Docker Isolation Is Enough

Docker does an excellent job of isolating processes, but container isolation should never be confused with application security.

A container can still expose:

vulnerable web applications
insecure APIs
weak authentication
exposed administration interfaces
outdated software

If an attacker reaches your application through HTTP, Docker has already done its job. Everything that happens after that depends on how your application and infrastructure are configured.

A common deployment looks like this:

Internet
      │
      ▼
Reverse Proxy
      │
      ▼
Docker Container

From Docker's perspective, everything is working correctly.

From an attacker's perspective, the application is still directly reachable.

Best Practice

Treat Docker as an application packaging tool, not a security boundary.

Application-layer protection should be considered separately from container isolation.

2. Believing HTTPS Equals Security

This is probably one of the most common misconceptions.

HTTPS encrypts traffic.

It does not determine whether requests are legitimate.

Once a TLS connection has been established, your server still has to process requests such as:

GET /.env
GET /.git/config
GET /phpmyadmin/
GET /wp-login.php

Every public-facing application eventually receives requests like these.

Sometimes they're vulnerability scanners.

Sometimes they're botnets.

Sometimes they're simply automated tools searching for common weaknesses.

TLS protects confidentiality during transmission.

It doesn't stop malicious HTTP requests from reaching your application.

Best Practice

Enable HTTPS by default, but don't mistake encryption for security.

Application-layer threats require application-layer defenses.

3. Ignoring Automated Bot Traffic

Many developers imagine attackers manually selecting targets.

Reality is much less exciting.

Most Internet-facing services are discovered automatically.

Bots continuously scan IPv4 address space looking for:

exposed CMS installations
leaked environment files
known framework vulnerabilities
default login pages
outdated dependencies

Your application doesn't need to be popular.

It only needs to respond.

One surprising lesson from operating public services is that attack traffic usually appears within minutes of exposing a new server.

Even relatively small applications often receive thousands of automated requests before receiving their first legitimate users.

Best Practice

Don't optimize only for legitimate traffic.

Plan for automated traffic as part of normal Internet operations.

Bot filtering and rate limiting should be considered baseline protections rather than optional features.

4. Depending Entirely on Infrastructure Security

Most deployment guides spend a lot of time discussing:

firewalls
private networks
SSH hardening
Docker networks
VPNs

These are all important.

However, they primarily protect infrastructure.

Modern attacks increasingly target applications instead.

Examples include:

SQL injection
Cross-site scripting
malicious request payloads
authentication abuse
credential stuffing
API enumeration

Infrastructure security alone cannot identify these behaviors because they often appear as perfectly valid HTTP requests.

This is where a Web Application Firewall (WAF) becomes useful.

Rather than protecting the operating system, it focuses on inspecting and filtering requests before they reach your application.

One practical deployment looks like this:

Internet
      │
      ▼
Self-hosted WAF
      │
      ▼
Nginx / Traefik / Caddy
      │
      ▼
Docker Applications

Placing the WAF in front of your reverse proxy allows suspicious traffic to be inspected before it reaches backend services.

Why I Chose a Self-Hosted WAF

Cloud WAF providers are excellent products.

For many organizations, they're probably the right choice.

They typically provide:

CDN integration
DDoS mitigation
managed infrastructure
simplified deployment

However, my requirements were slightly different.

I wanted application-layer protection that stayed inside my own infrastructure.

More importantly, I wanted visibility.

I wanted to understand:

What requests actually reached my servers?
Which endpoints were being scanned most frequently?
What kinds of payloads appeared every day?
Which rules should be adjusted for my own environment?

For self-hosted services and internal applications, keeping inspection close to the application made more sense than relying entirely on a cloud provider.

After evaluating several open-source options, I settled on SafeLine WAF.

Not because it's the only capable solution, but because it offered a good balance between deployment simplicity, application visibility, and operational overhead.

5. Never Looking at Your Logs

Many teams only investigate logs after something breaks.

Unfortunately, by that point the interesting events have already happened.

One unexpected benefit of introducing a WAF wasn't simply blocking requests—it was making malicious traffic visible.

Instead of reading thousands of raw access log entries, patterns became obvious.

For example:

repeated scans targeting WordPress installations on non-WordPress servers
automated requests searching for exposed Git repositories
SQL injection payloads against nonexistent endpoints
brute-force login attempts
bots cycling through known vulnerability lists

Individually, these events weren't particularly alarming.

Collectively, they revealed how noisy the public Internet really is.

Visibility changes the way you operate systems.

Once you understand normal background traffic, unusual behavior becomes much easier to identify.

Best Practice

Security tools shouldn't only block attacks.

They should also help you understand your environment.

A Practical Example

One of my current projects runs on a fairly standard VPS.

The infrastructure is intentionally simple.

Ubuntu Server

├── Docker Engine
├── SafeLine WAF
├── Nginx
├── PostgreSQL
└── Application Containers

There isn't a dedicated security team.

There isn't a SIEM platform.

There aren't enterprise security products running everywhere.

The goal is simply to reduce unnecessary risk while keeping operational overhead manageable.

In this environment, placing SafeLine in front of the reverse proxy provides three practical benefits:

filtering obvious malicious requests before they reach applications
applying centralized rate limiting across multiple services
providing visibility into application-layer traffic

None of these eliminate the need for secure coding or proper authentication.

They simply add another defensive layer without significantly complicating deployment.

When a Self-Hosted WAF May Not Be Necessary

A self-hosted WAF isn't the right answer for every environment.

You may not need one if:

every application is only accessible through a VPN
your infrastructure is completely private
you're already using an enterprise-managed cloud security platform
your team doesn't want to maintain another infrastructure component

Self-hosting always introduces additional operational responsibility.

Updates.

Monitoring.

Configuration management.

Backups.

These trade-offs should be considered before introducing any new infrastructure component.

Final Thoughts

Docker dramatically simplifies deployment, but it doesn't eliminate the need for application security.

As applications become Internet-facing, automated scanning and malicious traffic quickly become part of everyday operations.

The goal isn't to build an impenetrable system.

That's unrealistic.

Instead, the goal is to make attacks more difficult, reduce unnecessary exposure, and improve visibility into what's happening inside your infrastructure.

For smaller engineering teams, a practical security strategy doesn't need dozens of products.

It starts with understanding where your current defenses stop.

Docker isolates processes.

HTTPS encrypts traffic.

Firewalls protect networks.

A Web Application Firewall fills a different role by inspecting application-layer requests before they reach your services.

Choosing between a cloud WAF and a self-hosted solution ultimately depends on your architecture and operational preferences.

If you value local control, application visibility, and protecting self-hosted services without relying entirely on external infrastructure, a solution like SafeLine WAF is well worth evaluating—not as a replacement for good security practices, but as another layer in a defense-in-depth strategy.

Key Takeaways

Docker isolation does not equal application security.
HTTPS encrypts traffic but does not block malicious requests.
Automated bots continuously scan every public-facing service.
Infrastructure security and application security solve different problems.
Visibility is one of the most valuable security capabilities you can add.
A self-hosted WAF can provide application-layer protection while keeping security controls close to your own infrastructure.

How I replaced hours of manual work with a self-hosted AI agent

Sat, 02 May 2026 01:38:16 +0000

Every time I publish content I burn over ten hours putting it everywhere else. Articles to Medium, Substack, Dev.to, Hashnode. Posts to LinkedIn personal and company. Threads to Twitter. Comments across Reddit and trade communities. Each platform wants the content slightly different. Each one needs a canonical URL pointing back to the source. Each one is fifteen to forty minutes of copy paste, format fixing, tag selecting.

Ten plus hours a week of distribution across articles, posts, comments, syndication. Pure copy-paste with no thinking attached. The kind of work that gets pushed to evenings and weekends because there is always something more important to do during business hours.

I just spent a weekend replacing it with a self-hosted open source AI agent called OpenClaw, running on a small Docker-sandboxed VM with ChatGPT Plus as the brain. Starting cost around thirty-two dollars a month. Scales up to forty-four if you push the box harder. Less than the coffee budget either way.

Here is the full build, including the security layer most self-hosted AI agent tutorials hand-wave their way through.

$32+/mo
Total monthly cost (VM + LLM)

~4 hrs
Setup time end to end

10+ hrs/wk
Manual work being replaced

Why self-host instead of using a SaaS

You have three real options when you want an AI agent doing browser-driven work for you on a recurring basis.

SaaS browser agent — Browserbase, Skyvern Cloud, Multi-on, OpenAI Operator. Easy to start. Ninety-nine to two hundred dollars a month. Your cookies, your profiles, your audit logs all sit on their infrastructure.
Build your own from scratch — Python with playwright or browser-use as a library. Full control. All the orchestration is on you to write and maintain.
Self-host an open source agent — Run something like OpenClaw or browser-use in a Docker container on a small VM you own. Control plus low cost. More setup than SaaS but a lot less than building from scratch.

For my use case, which is content distribution with no sensitive financial or client data on the path, self-hosting wins on three counts.

Cost. Thirty-two dollars a month versus ninety-nine to two hundred dollars a month for SaaS. Over a year that is around two thousand dollars saved on a workload neither side handles dramatically better.

Control. Every cookie, profile, screenshot, and audit log sits on infrastructure I own. If a platform changes its UI tomorrow and breaks the agent, I can patch it inside an hour. With SaaS I would wait for the vendor.

Reusability. The same VM that runs the syndication agent already runs my Reddit scout cron job and will host other automations as I build them. The marginal cost of the next workflow is zero.

Picking the agent

Five options I looked at seriously before settling on one.

browser-use — Python library, MIT licensed, around thirty thousand stars on GitHub. Fantastic if you are happy writing the orchestration yourself. I am not, for this workload.
Skyvern — Heavier autonomous browser agent built for enterprise scraping. Overkill for content syndication.
Manus — Closed and hosted. Not self-hostable.
Anthropic Computer Use — Capable but ties you to Claude API pricing, which gets expensive fast on agentic workloads where every step is a model call.
OpenClaw — Open source, founded by Peter Steinberger, designed around messaging-platform control loops (Discord, Telegram, Slack). Steinberger joined OpenAI in February but the project is now run by a non-profit foundation.

OpenClaw won for three reasons. Discord-native control loop, which lined up with how I already work. Self-hostable in Docker out of the box. And it supports the OpenAI Codex provider, which means I can run it on a flat twenty dollar a month ChatGPT Plus subscription instead of paying per token.

The stack

Five pieces, nothing exotic.

VM — DigitalOcean droplet, Ubuntu 24.04 LTS. Twelve to twenty-four dollars a month depending on size.
Sandbox — Docker plus Docker Compose, with the agent in its own container, dedicated network, capability drops, and a workspace mounted from the host.
Agent — OpenClaw gateway running from the official ghcr.io pre-built image.
Interface — A private Discord server with the bot scoped to specific channels, DMs disabled entirely.
Brain — ChatGPT Plus with the OpenAI Codex provider connected to OpenClaw. GPT-5.5 inside rate limits, twenty dollars a month flat.

Total monthly cost lands between thirty-two and forty-four dollars depending on how hard you push the VM. Setup time around three to four hours of focused work, most of it spent on the security layer rather than OpenClaw itself.

Provisioning the droplet

Pick at least the twelve dollar plan. The six dollar plan with 1GB of RAM is dead on arrival once Chromium plus the agent plus plugins fire up.

2GB at $12 works but is tight. Chromium alone wants 500 to 800MB. OpenClaw plus its plugins eat another few hundred. Once a browser session is active per platform, you are running close to the ceiling. Fine for one workflow, fragile under multiple.

If you plan to run multiple browser sessions in parallel, layer in Reddit scout or scheduled cron jobs, or expand to other automations on the same box, the four GB plan at twenty-four dollars a month is the comfortable spot. I started at twelve and will bump as the workload grows.

Ubuntu 24.04 LTS gives the longest support window and the best Docker compatibility. Add your SSH public key during droplet creation, enable IPv6, choose the closest region.

The droplet boots in about ninety seconds. The interesting part is what you do to it before installing anything.

Hardening the VM (the part most tutorials skip)

An autonomous agent that can drive a browser is a fat target for anyone who finds your IP. Default Ubuntu is not hardened for this. Three layers I add before installing anything else.

SSH lockdown

Edit /etc/ssh/sshd_config:

PermitRootLogin no — root cannot SSH in directly. Anyone trying needs to know your username, not just the universal root.
PasswordAuthentication no — passwords are off entirely. Only SSH keys work.
PubkeyAuthentication yes — explicitly on.

Validate with sudo sshd -t before restarting the service. Test from a second SSH window before closing the first one. If you brick your config you still have a live session to revert from.

Firewall

UFW, default deny inbound, default allow outbound. Only port 22 open inbound. Nothing else needs to be reachable from the internet on this box. The agent reaches out, never the other way around.

sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp sudo ufw enable

Background defenses

fail2ban for SSH brute-force protection. unattended-upgrades for automatic security patches. Both run by default after install with sensible defaults.

sudo apt install -y fail2ban unattended-upgrades ufw

That is the baseline. The combination of key-only SSH, denied-by-default firewall, fail2ban, and auto-patches takes maybe fifteen minutes and removes most of the drive-by attack surface.

Docker install

Use the official Docker repo, not the version Ubuntu ships in apt. The Ubuntu default is older and missing features OpenClaw uses.

Standard install steps from docs.docker.com (https://docs.docker.com/engine/install/ubuntu/). Then add yourself to the docker group so you do not need sudo for every command.

sudo usermod -aG docker $USER

Log out, log back in, and verify with docker run hello-world. If you see the welcome message, Docker is set.

Directory structure

Pre-create the directories OpenClaw will mount, with restrictive permissions. Owned by your non-root user, mode 700 so nothing else on the system can read them.

`sudo mkdir -p /opt/openclaw/{config,profiles,workspace}
sudo mkdir -p /opt/discord-bot
sudo mkdir -p /var/log/openclaw

sudo chown -R $USER:$USER /opt/openclaw /opt/discord-bot /var/log/openclaw
chmod 700 /opt/openclaw /opt/openclaw/config /opt/openclaw/profiles /opt/openclaw/workspace /var/log/openclaw`

Two notes on this layout.

Separate Chrome profiles per platform. Inside /opt/openclaw/profiles there is a sub-directory per platform: medium, linkedin, substack, devto. Each platform gets its own scoped Chrome profile with only that platform logged in. If Medium ever gets compromised, LinkedIn is unaffected because the cookies live in a different profile entirely.

Logs outside the agent dir. /var/log/openclaw is the audit log destination. It is outside the OpenClaw config tree on purpose, so a misbehaving agent cannot rewrite its own history.

OpenClaw setup

Clone the repo and pull the pre-built Docker image. Building locally works too but takes longer and burns CPU you do not have on the small droplet.

`cd /opt/openclaw
git clone https://github.com/openclaw/openclaw.git repo

cat > /opt/openclaw/openclaw-env.sh <<'EOF'
export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
export OPENCLAW_CONFIG_DIR="/opt/openclaw/config"
export OPENCLAW_WORKSPACE_DIR="/opt/openclaw/workspace"
export OPENCLAW_GATEWAY_BIND="lan"
export OPENCLAW_SANDBOX="1"
export OPENCLAW_TZ="UTC"
EOF
chmod 600 /opt/openclaw/openclaw-env.sh

source /opt/openclaw/openclaw-env.sh
cd /opt/openclaw/repo
./scripts/docker/setup.sh`

The setup wizard walks through everything. Workspace path, gateway port, gateway bind, auth method, channel selection, DM policy, search provider, skills.

Two settings to get right at this stage.

Loopback Docker port mapping

OpenClaw exposes the Control UI on port 18789. By default Docker maps that port to 0.0.0.0:18789, meaning anyone on the internet who scans port 18789 on your VM gets the gateway. UFW does not always block Docker traffic correctly because Docker manipulates iptables directly.

Fix it at the Docker level by overriding the port mapping to bind only to 127.0.0.1 on the host.

`cat > /opt/openclaw/repo/docker-compose.override.yml <<'EOF'
services:
openclaw-gateway:
ports: !override

"127.0.0.1:18789:18789"
"127.0.0.1:18790:18790"
EOF`

The !override tag is critical. Without it Docker Compose merges the port arrays and you end up with both bindings active, which causes a port conflict and cryptic startup errors.

SSH tunnel for the Control UI

Now the gateway is invisible from the public internet. To access the Control UI from your laptop, set up an SSH tunnel.

ssh -L 18789:127.0.0.1:18789 your-droplet-alias

Then visit http://localhost:18789/ in your laptop browser, paste the gateway token, and you are in. Close the SSH session, the dashboard is gone. No public exposure, no separate auth layer to manage, no port to forget about.

Discord setup

OpenClaw is not just a bot, it is an agent that uses Discord as a control loop. The wiring matters as much as the install.

Server. Private, no invite links, two-factor required for moderation. I am the only user.

Channels. Ten channels, scoped per workflow. Channel allowlist enabled in OpenClaw so the bot only acts in these channels and ignores everywhere else.

#commands — where I fire commands at the agent
#confirm — bot drops confirmations before destructive actions
#articles, #comments, #posts, #reddit — activity logs per workflow
#errors — anything that failed
#dry-runs — what the bot would have done in test mode
#screenshots — visual proof of every successful action
#kill-switch — emergency stop channel

DMs disabled. The agent does not respond to direct messages from anyone, including me. All commands must come through the private server. One less attack surface for prompt injection or social-engineering attempts.

User ID check. The bot listener verifies the author of every command against my specific Discord user ID before executing. If anyone else somehow ends up in a position to message the bot, their commands get silently dropped.

The LLM auth strategy

The piece most people get wrong on cost. There are three real options for the agent brain, and the math is not what you would expect.

OpenAI API — Pay per token. At low volume around five to fifteen dollars a month. Scales linearly with usage.
Anthropic Claude API — Same pay-per-token model but slightly more expensive on agentic workloads. OpenClaw originally supported Claude session auth but Anthropic blocked plan-based session use in early 2026.
ChatGPT Plus with Codex provider — Twenty dollars a month flat. Inside rate limits you get GPT-5.5 unlimited. OpenClaw has native support for the Codex provider so the agent can drive it the same way it would the API.

I picked Plus plus Codex for cost predictability. Twenty dollars a month is twenty dollars a month no matter how many syndications I run. The pay-per-token paths are cheaper at very low volume but get expensive fast on agentic workloads where every step is a model call. If volume scales ten-x I will reconsider, but for now this is the cleaner shape.

What the agent can and cannot access

The hardest part of running an autonomous agent is being honest about the blast radius. Mine runs in a tight box. Here is exactly what is inside the box and what is not.

What the agent can reach

Chrome profiles for Medium, LinkedIn, Substack, dev.to (real accounts logged in)
Discord (only the channels in the allowlist)
Outbound internet (for posting, no inbound)
Its own mounted directories under /opt/openclaw
The OpenAI Codex provider for LLM calls

What the agent cannot reach

Banking, primary email, password manager — none of these have logins in the agent profiles
My laptop — the agent runs on the VM, my Mac is unreachable from the container
Any other site or service I run — no NeverMiss admin access, no client systems, no databases
The host filesystem outside its mounts — Docker capability drops plus read-only root filesystem on the container itself
Other containers on the same VM — the agent runs on a dedicated Docker network

Three rules I follow

Never give it credentials I would not be okay with leaking. If I would not paste a credential into a Slack channel, it does not go in the agent profile.
Two-factor on every account it touches. If a session cookie ever gets exfiltrated, the attacker still hits the 2FA wall.
Use dedicated syndication accounts where it makes sense. My primary LinkedIn stays manual. Syndication LinkedIn is the agent's. Same for any platform where account safety matters more than convenience.

First test

Once the gateway is healthy, the bot is online in Discord, and the SSH tunnel reaches the Control UI, the test loop is short.

From the #commands channel:

/dryrun on /syndicate self-hosted-ai-agent-vm

Dry-run mode runs the entire syndication workflow except the final publish click. Every step the agent would take gets logged to #dry-runs with screenshots. I read through the Discord channel and verify the agent navigated correctly, generated a sane intro, set the canonical URL, picked the right tags. If anything looks off, I tweak the system prompt and re-run.

Once dry-runs land cleanly, flip to live mode and run the same command again. The agent posts. Screenshots and post URLs hit Discord within a couple minutes.

I have ran dry-runs of this exact workflow against the cold-caller article I wrote two weeks ago. Output looked clean. The full live runs across all platforms ship in the next couple of weeks once I have completed Medium and Substack login flows for the agent's profile.

What broke during setup

Honest list of the things that cost me time so you do not lose the same hours.

Sudo password. Forgot it on day one. DigitalOcean recovery console refused to open with a stock auth flow, took an hour to figure out the right path. Lesson: password manager entry the moment you set the password.

Docker Compose port merging. Spent an hour on a "address already in use" error. The fix turned out to be the !override tag in the override file. Without it Docker Compose merges port arrays from base and override, both bindings activate, conflict.

Loopback bind too tight. First pass, I bound the gateway to container loopback (127.0.0.1 inside the container). That blocks the Docker port mapping entirely because Docker forwards to the container's 0.0.0.0, not its 127.0.0.1. Switched to LAN bind inside container plus loopback bind on the Docker port mapping. Both layers required for SSH tunnel access.

Anthropic session block. Was originally going to wire Claude Plus into OpenClaw via session auth. Anthropic blocked that path Q1 2026. Switched to OpenAI Codex via ChatGPT Plus, which actually turned out cheaper for this workload.

What is next

Right now: gateway is healthy, bot is online, Control UI is accessible only via SSH tunnel, agent is in dry-run mode by default. Real syndications start this week.

I will ship part two in two weeks with the actual numbers.

First-run results across Medium, LinkedIn, Substack, dev.to
Where the agent succeeds and where it trips on unfamiliar UI states
Real time saved per article including screenshots
Whether platform anti-bot detection becomes an issue
Cost-per-syndication breakdown across LLM and infrastructure

If you liked this, my last long-form was on the AI cold-caller I built for HVAC outbound (https://nevermisshq.com/blog/ai-cold-caller-hvac-outbound-build) — same NeverMiss, very different stack, full post-mortem on what worked and what did not.

If you run a home service business and want this kind of automation built into your operations rather than as a hobby project on a $12 droplet, that is what NeverMiss does day to day. Book a call below.

FREYA Personal — Sovereign AI Assistant

Sat, 25 Apr 2026 18:00:00 +0000

Shipped my first product today after months of nights and weekends. FREYA is a personal AI assistant that runs entirely on the user's own machine — no cloud, no API calls out, no telemetry, no account required.
Technical:

Code-locked, cryptographically validated build
Local SQLite memory database (freya_memory.db) stays on the user's disk
Zero external calls at runtime — no heartbeat ping, no license server call-home
One-click install for non-technical users
Tested on hardware from mini PCs up to a 40GbE cluster

Pricing:

$49 one-time, Personal edition (one user, one machine)
Family / Small Business / Enterprise editions coming

Why I built it:
Big Tech can't sell a $49 one-time local AI without cannibalizing their $20/month subscription revenue. That gap is where small shops win. Built this for the people who want ChatGPT-style help without Big Tech reading every word they type.
Built in Idaho by Teton Data Systems LLC. Happy to answer technical questions about the architecture.