Coder Legion - Recent posts tagged docker

How to Change the WAF Web Console Listening Port When SafeLine Stays on 9443

Sat, 31 Oct 2026 02:47:24 +0000

Changing the WAF web console listening port looks like a one-line edit, but the SafeLine deploy guide only treats one environment key as that port. This troubleshooting note covers one concrete misconfiguration: the operator stored a new port in MGT_PROXY, left MGT_PORT at 9443, and opened a browser URL built from the MGT_PROXY number. The management page did not load. The fix is confirmed when the browser shows the web console on the port named by MGT_PORT, and the administrator reset command still prints a usable login.

SafeLine is a self-hosted web application firewall. Deployed in front of an application, it works as a reverse proxy: clients reach the WAF first, and the WAF filters and monitors HTTP traffic before a request is forwarded. That protection path is not the management console. The console is the admin page documented in the deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy. That guide names the console port with MGT_PORT, described as the web console port to be used. The sample .env sets MGT_PORT=9443, and the Use Web UI section says to open https://<safeline-ip>:9443/. Those two statements are the pair you have to keep aligned.

The misconfiguration

Manual setup creates /data/safeline, downloads compose.yaml, and writes .env in that directory. The sample sets MGT_PORT=9443 and MGT_PROXY=0, plus directory, image, database password, subnet, and token values. MGT_PORT is the web console port to be used. MGT_PROXY is the number of console proxy layers. The same guide says MGT_PROXY should only be used when configuring the proxy for the console, and that the default 0 means no proxy is configured. See https://docs.waf.chaitin.com/en/GetStarted/Deploy.

The failed change ignored that split. The operator wanted the console off the sample port, replaced 0 in MGT_PROXY with the desired port, saved the file, and browsed to https://<safeline-ip>: plus that MGT_PROXY value. MGT_PORT was still 9443. The deploy guide never says MGT_PROXY selects the listening port. A non-zero value is a proxy-layer count for a real console proxy setup. Writing a port there does not move the URL under Use Web UI.

A related mistake shows up after login. The application guide at https://docs.waf.chaitin.com/en/GetStarted/AddApplication tells you to open Applications, choose Add Application, and enter Domain, Port, and Upstream. Port there is the port SafeLine will listen on for the original app, such as 80 or 443, with SSL checked for HTTPS apps. That field is not MGT_PORT. Changing it does not rewrite the console address https://<safeline-ip>:9443/.

What to compare before you call it a port change

Use the deploy guide as the checklist and touch only the key it defines as the console port.

Open .env in the SafeLine directory, shown as /data/safeline in the manual steps. Read MGT_PORT first. That is the web console port to be used, and the published example is 9443. Read MGT_PROXY next. Leave it at 0 unless you are actually configuring proxy layers for the console. Do not store a listen port in MGT_PROXY. Do not use the Applications Port field as the console setting. That field belongs to the protected site.

The guide applies the environment file when you launch with docker compose up -d from the SafeLine directory. The worked example then opens the console at https://<safeline-ip>:9443/, which matches MGT_PORT=9443. If MGT_PORT is still 9443, that is the documented console address, even if another number was typed into MGT_PROXY or into an application form. The sources do not publish a separate post-install migration log, a firewall recipe, or a certificate recipe for an alternate console port. They also do not show a command whose only job is to rebind the console after a later edit. If the page fails on some other number, treat that as a URL mismatch against MGT_PORT, not as proof that the console moved.

If you are still in the environment-writing step, declare the console port only with MGT_PORT, then launch with the documented docker compose up -d command, and open the console with that same port value. The official success case in the guide is port 9443. Keep the browser pattern identical to Use Web UI, and do not assume an undocumented log line will announce the bind.

The screen that confirms the fix

Restore MGT_PROXY to 0 if you are not configuring a console proxy. Point the browser at the port stored in MGT_PORT. In the documented installation that value is 9443, so the confirming page is https://<safeline-ip>:9443/. The deploy guide says opening this page is how you use the web UI after installation. Seeing that console page is the first confirmation. A connection error or a timeout on any other port is the mismatch, not a successful port move.

The second confirmation is the account step, not a guessed log path. Run docker exec safeline-mgt resetadmin. When it succeeds, the guide says you must remember the content, then shows the initial username admin, the initial password, and Done. Log in with that username and password on the console page that just loaded. A completed login on the MGT_PORT URL is the screen that proves you are on the web console the install guide configured.

Do not use a block page as that proof. The application guide says a blocking page means SafeLine defended a test attack against a protected site, and that attack detail is viewed from the web console attack list. A block page means you reached a protected application flow. It does not confirm that MGT_PORT changed, and it does not confirm that MGT_PROXY was a valid place to store a port.

If resetadmin succeeds but the browser still targets the wrong port, the account step is not the failure. Read MGT_PORT again. The password block only helps after the console page itself is the one from Use Web UI.

Automatic install does not add a different confirmation. After the documented install command finishes, the deploy guide sends you to Use Web UI, which is the same https://<safeline-ip>:9443/ page. The success text does not print an alternate console port.

What this check does not claim

The home overview at https://docs.waf.chaitin.com/en/home describes SafeLine as a self-hosted WAF and reverse proxy with defenses for web attacks, bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. None of those behaviors is a console port switch. Rate limiting, CAPTCHA challenge, authentication challenge, and dynamic protection are traffic controls for protected apps, not substitutes for MGT_PORT.

This note does not claim that every numeric port is suitable, and it does not add steps the deploy guide does not contain. If the console page does not load on the port written in MGT_PORT, stop and re-check the variable names rather than stacking rewrites that the sources do not describe. After the console loads, protecting an application is still a separate task: add Domain, Port, and Upstream, then resolve the domain to the SafeLine server, as https://docs.waf.chaitin.com/en/GetStarted/AddApplication describes.

Why does the console still open on 9443 after I edited the environment file?

Because the sample and the Use Web UI section both use 9443, and that number comes from MGT_PORT, not from whichever numeric field you edited. If MGT_PORT is still 9443, the documented console URL is still https://<safeline-ip>:9443/. A change to MGT_PROXY or to an application Port does not replace that page. The variable definitions are in https://docs.waf.chaitin.com/en/GetStarted/Deploy.

Is the application port the same as the web console port?

No. In Add Application, Port is the port SafeLine listens on for the original app, with 80 or 443 given as examples. The web console port is MGT_PORT in .env. Mixing those fields is the misconfiguration above. The application fields are documented at https://docs.waf.chaitin.com/en/GetStarted/AddApplication.

What does MGT_PROXY change if it is not the listen port?

The deploy guide defines MGT_PROXY as the number of console proxy layers. It should only be used when configuring the proxy for the console. The default is 0, which means no proxy is configured. It is not documented as the web console listening port.

Which screen confirms the console port is the one I intended?

Load https://<safeline-ip>: followed by the MGT_PORT value. For the documented example, that is https://<safeline-ip>:9443/, and the web console page should appear. Then run docker exec safeline-mgt resetadmin and confirm the initial username admin and the Done line before you log in. That loaded console, not a timeout on another port, is the confirmation described in https://docs.waf.chaitin.com/en/GetStarted/Deploy.

Do I need a new administrator password after correcting the port?

Only if you run the documented reset. docker exec safeline-mgt resetadmin prints the initial password and Done. Correcting MGT_PROXY back to 0, or opening the URL that already matches MGT_PORT, does not by itself rotate that password. Use the credentials the command prints if you choose to reset, and use them on the console page that matches MGT_PORT.

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

Why I Change the WAF Web Console Listening Port Before Turning Protection On

Sat, 31 Oct 2026 02:46:53 +0000

Before I turn protection on for a live site, I walk a decision checklist. The step I no longer skip is the management listener. Learning how to change the WAF web console listening port belongs in that checklist, because the console is where I will later read blocks, challenges, and attack detail. If I cannot open it on a port I chose, I am not ready to point a domain at the proxy.

SafeLine is a self-hosted web application firewall. Placed in front of an application, it works as a reverse proxy: clients reach SafeLine first, it filters and monitors HTTP and HTTPS traffic, and it forwards traffic it treats as safe to the original application. The product introduction lists defenses for web attacks, proactive bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Those controls are useless to me if the console listener was an accident.

Set the console port before the first launch

The manual deploy page is the place that defines this choice. In the environment file, MGT_PORT is the web console port to be used. The sample sets MGT_PORT=9443, and the same page tells you to open https://<safeline-ip>:9443/ after startup. I treat 9443 as the documented sample, not as a port every host must keep. When that port is already taken, or when my access policy expects the console elsewhere, I change MGT_PORT in .env before I run docker compose up -d. These pages do not describe a console-port switch inside the application dialog, so I do not wait until after DNS and hope one appears.

The automatic installer is a narrower path. The deploy guide gives one command and then sends you to the web UI, which it shows on port 9443. It does not document a port flag on that command. If I need a non-default console port, I use the manual environment file, where MGT_PORT is explicit, and I decide it before protection is turned on. See the deploy guide: https://docs.waf.chaitin.com/en/GetStarted/Deploy

MGT_PROXY is a different knob. The guide defines it as the number of console proxy layers, to be used only when configuring a proxy for the console. The default is 0, which means no proxy is configured. Choosing another MGT_PORT does not, by itself, mean I should change MGT_PROXY.

Keep that port off the public site path

Turning protection on is an application change, not a console login. In Applications, Add Application asks for three facts. Domain is the original app domain, hostname, or IP. Port is the port SafeLine will listen on for that app, such as 80 or 443, with the SSL option checked for HTTPS apps. Upstream is the real address used to forward cleaned traffic. After that, the domain is resolved to the IP of the server where SafeLine runs. Visitors then reach the site through SafeLine. The application steps are documented at https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Those fields are easy to mix up with MGT_PORT. They are not the same decision. If I set the application listen port to the console port, administration and the public site fight over one listener. My order is console port first, application listen port second, and DNS last.

I also refuse to add an application until the host matches the documented minimums: Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, 1 CPU core, 1 GB of memory, 5 GB of disk, and a CPU with ssse3. The deploy page lists checks such as uname -m, docker version, docker compose version, free -h, df -h, and lscpu | grep ssse3. I run the ones that apply to this machine instead of assuming a laptop test equals the server.

ARM is a hard stop in that same page. SafeLine installed on ARM requires a Pro license to work properly, and the Personal Edition is not supported on ARM. If I am on ARM and that license does not apply, I stop before DNS. The LTS choice is equally explicit: RELEASE=-lts selects the LTS line, which the guide says will no longer be maintained starting from 9.1.0-LTS on 14 August 2025. It recommends moving to the latest version, and waiting about a month after a new release if I want caution. I write that choice down before traffic depends on it.

Secrets come before exposure. The manual steps generate DETECTOR_MGMT_TOKEN and MGT_INTERNAL_TOKEN as 64-character hex values, generate a 16-character alphanumeric DETECTOR_AES_KEY, write them into .env, and set chmod 600 on that file. I do not launch with the sample placeholders still in place. After docker compose up -d, which can take several minutes, I open the console on the port I set. I run docker exec safeline-mgt resetadmin and I keep the initial username and password it prints. The guide shows that initial username as admin. If that page does not load, the listening-port decision is still open, and protection is not ready.

Name the protection you are actually turning on

The introduction lists coverage for SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, HTTP flood, and bot abuse: https://docs.waf.chaitin.com/en/home

The same pages name rate limiting, CAPTCHA challenge, authentication challenge, and dynamic protection. Rate limiting throttles traffic over defined limits, including DoS attempts, bruteforce attempts, and traffic surges. CAPTCHA is documented as a challenge that lets human users through while blocking crawlers and bots. Authentication challenge, when turned on, requires a password or the visitor is blocked. Dynamic protection, when turned on, dynamically encrypts HTML and JS on each visit. I pick the controls this application needs. I do not flip every switch because the container started.

Before I call the site protected, I use the documented probes: a SQL injection query, an XSS payload, a path traversal sequence, a code injection string, and an XXE doctype, with my own domain in place of the example. A blocking page means that request was defended. I then open the attack list in the console and click detail. An empty list sends me back to domain, listen port, upstream, and DNS. It does not send me to a victory message.

The checklist I keep is short. Confirm the host, and stop on ARM if the documented license requirement is not met. Set MGT_PORT to the console port I will use, and leave MGT_PROXY at 0 unless the console itself is proxied. Generate the documented secrets and restrict .env. Launch, log in with the resetadmin output, and only then add Domain, Port, and Upstream. Resolve DNS last. Judge the result from the blocking page and the attack detail view.

How do I change the WAF web console listening port?

Set MGT_PORT in the SafeLine .env file used by the manual compose deploy. The deploy guide defines that variable as the web console port to be used and shows 9443 in the sample, with the console at https://<safeline-ip>:9443/. Put the port you want in MGT_PORT, then start with docker compose up -d. That is a console environment setting. It is not a field in Add Application, and these pages do not describe a later port control in the UI.

Is the web console port the same as the application listen port?

No. MGT_PORT is only the web console port. In Add Application, Port is what SafeLine listens on for the protected app, such as 80 or 443, and HTTPS apps need the SSL option. Upstream is the real address that receives forwarded traffic. Changing the console port does not change the public site listener.

What should I verify before I turn protection on?

Match the documented host minimums, including Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, memory, disk, and ssse3. On ARM, confirm the Pro license requirement, because the Personal Edition is not supported there. Generate the documented secrets, open the console on your MGT_PORT, and log in with the account printed by docker exec safeline-mgt resetadmin. Add the application and point DNS at the SafeLine server only after that login works.

Does a different console port require MGT_PROXY?

No. MGT_PROXY is the number of console proxy layers. Use it only when you are configuring a proxy for the console. The default of 0 means no proxy is configured. A custom MGT_PORT does not imply a console proxy.

How do I know the protection decision worked?

Send the documented SQL injection, XSS, path traversal, code injection, and XXE test requests to your own domain. Expect the blocking page, then open the console attack list and click detail. If you cannot open the console, fix the listening port and the admin login before you judge the site protected.

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 Reset the WAF Admin Account Inside Docker

Sat, 31 Oct 2026 02:37:39 +0000

Losing the SafeLine console password usually starts with a reasonable but wrong edit. After installation, the web UI is opened at https://<safeline-ip>:9443/, and the deploy guide does not store that login in the Compose environment file. Resetting the administrator account is a container command. The failure mode below is one concrete mix-up: treating POSTGRES_PASSWORD as the console password, then trusting a restart that never printed a new admin credential.

What was misconfigured

A manual install keeps SafeLine configuration and data in a directory you create. The deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy uses /data/safeline as the example. Inside it, .env holds SAFELINE_DIR, IMAGE_TAG, MGT_PORT, POSTGRES_PASSWORD, SUBNET_PREFIX, and several generated secrets. That same guide defines POSTGRES_PASSWORD as the Postgres database initialization password. It is consumed when the database is initialized. It is not the account you type into the management UI.

The misconfiguration looks like this. The operator cannot log in, opens .env, replaces POSTGRES_PASSWORD, optionally rewrites DETECTOR_MGMT_TOKEN or MGT_INTERNAL_TOKEN, and runs docker compose up -d again. Compose can bring the stack process up. That result does not print an administrator username or a console password. The web account was never that database variable, so the edited string is the wrong secret for the login form.

File mode is a related dead end. The guide sets .env to mode 600 and restricts resource directories such as resources/mgt and resources/postgres/data. Those permissions protect local secrets and sockets. Changing them does not rotate the console user.

Reset the account inside the management container

Use the procedure in the deploy guide, in order.

Confirm the host meets the documented dependencies before you blame the password command: Linux, x86_64 or arm64, Docker 20.10.14 or above, and Docker Compose 2.0.0 or above. The guide also lists a minimum of 1 core CPU, 1 GB memory, and 5 GB disk, plus the ssse3 CPU flag. Those checks explain a stack that never became ready. They are not a second password store.

From the SafeLine directory that contains compose.yaml and .env, start the services with docker compose up -d. The guide warns that this can take several minutes. When it finishes, request the administrator account from inside the management container:

docker exec safeline-mgt resetadmin

The container name in that command is safeline-mgt. Do not point docker exec at the Postgres image named in .env, and do not expect the automatic installer shell to reprint the password later. The documented recovery for the administrator account is this exec, described under Get Administrator Account in https://docs.waf.chaitin.com/en/GetStarted/Deploy.

The screen that confirms the fix

Success is a terminal screen, not a Compose health line. The deploy guide says that after the command succeeds you must remember the printed content. The confirming text begins with the sentence Please must remember this content. It then prints three [SafeLine] lines: initial username admin, initial password, and Done. The password in the guide is shown masked. On your host, copy the characters that appear in that password field. Asterisks in the documentation are not the credential.

If that remembered-content screen is absent, the reset is not confirmed. Do not fall back to POSTGRES_PASSWORD, and do not paste a token from .env into the login form. DETECTOR_MGMT_TOKEN and MGT_INTERNAL_TOKEN are internal values written during setup. The guide does not present them as console passwords.

After the screen is present, open the console with HTTPS on the SafeLine host and the console port. The documented URL is https://<safeline-ip>:9443/. MGT_PORT is defined as the web console port, and the sample .env sets it to 9443. If you changed MGT_PORT before startup, use that port instead. MGT_PROXY is the number of console proxy layers. The sample keeps it at 0 when no console proxy is configured. It does not replace resetadmin.

The guide then says to enter the password from the previous step, after which you are logged into SafeLine. A successful login with that exact password is the second confirmation. Seeing a block page on a test request only proves that a protected application filtered an attack, as described in https://docs.waf.chaitin.com/en/GetStarted/AddApplication. It does not prove that the admin reset ran.

What not to reset by accident

SafeLine is a self-hosted web application firewall, per https://docs.waf.chaitin.com/en/home. Deployed in front of an application, it is a reverse proxy: clients reach SafeLine first, malicious HTTP and HTTPS traffic is filtered, and safe traffic is forwarded to the upstream. The same overview lists defenses against attacks such as SQL injection, XSS, command injection, path traversal, SSRF, and brute force, plus rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS protection. None of that is configured by the admin reset command.

Application proxy settings are entered after login. The protecting-applications guide tells you to open Applications, add an application, and set domain, listen port, and upstream. Resetting the console user does not document a change to those fields.

Do not uninstall to recover a password. Uninstall, in the same deploy guide, is docker compose down in the SafeLine directory and then removal of that directory. That deletes local configuration and data. It is a different operation from docker exec safeline-mgt resetadmin.

Close the loop with the original mistake

Before you leave the host, check four facts against the screen you just saw. The stack was started with docker compose up -d. The reset targeted safeline-mgt. The terminal showed the remember-this-content notice, username admin, a password, and Done. The browser used HTTPS and MGT_PORT, normally 9443, with the password copied from that screen rather than from POSTGRES_PASSWORD.

Why does editing POSTGRES_PASSWORD fail to reset the console admin?

The deploy guide defines POSTGRES_PASSWORD as the Postgres initialization password in .env. The documented way to obtain the console administrator account is docker exec safeline-mgt resetadmin. A Compose restart can leave the web password unchanged because that variable was never the console credential.

How do I know the container reset actually finished?

The confirming screen is the output documented for resetadmin: the notice to remember the content, then [SafeLine] lines for initial username admin, initial password, and Done. No other log in the install guide is described as that credential. If those lines are missing, there is no new admin password to type.

Which URL matches the password I just reset?

Log in at https://<safeline-ip>:9443/ unless MGT_PORT in .env was set to another console port. Use HTTPS. The upstream site you are protecting is not the management UI, and a guess on the application listen port will not submit this credential to the console.

Can I reset the admin account before docker compose up finishes?

The guide places Get Administrator Account after Launch SafeLine. Run docker compose up -d first and allow the start, which may take several minutes. resetadmin is an exec into safeline-mgt, so the management container has to be there for the command to return the success screen.

Will this admin reset delete applications or replace the database password?

The documented command prints an initial username and password for the console. It does not say that applications, upstreams, or POSTGRES_PASSWORD are rewritten. Removing the install directory is the uninstall path, and that path does delete SafeLine data, so keep uninstall and admin reset separate.

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

Why I Run a Checklist Before Turning Protection On

Sat, 31 Oct 2026 02:37:07 +0000

I do not turn protection on in the same hour I install a web application firewall. SafeLine sits in front of the origin as a reverse proxy, so a rushed cutover can lock operators out of the console or send visitors to the wrong upstream. The product documentation describes SafeLine as a self-hosted WAF that filters and monitors HTTP traffic between a web application and the Internet, blocking malicious requests and stopping unauthorized data from leaving the app by applying policies that separate malicious traffic from safe traffic (https://docs.waf.chaitin.com/en/home). That architecture is why I keep a decision checklist, and why the first operational question is how to reset the WAF admin account inside Docker before any site depends on the proxy.

Confirm the host before you trust the console

The deploy guide sets a floor I will not negotiate: 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. The same page lists the checks I actually run: uname -m, docker version, docker compose version, processor and memory inspection, df -h, and an lscpu filter for ssse3 (https://docs.waf.chaitin.com/en/GetStarted/Deploy). If any line fails, protection stays off. On ARM, that guide states that SafeLine requires a Pro license to work properly and that the Personal Edition is not supported on ARM. I treat that as a stop, not a footnote. I also decide the release track before launch. The guide says the LTS line will no longer be maintained starting from 9.1.0-LTS (14 August 2025) and strongly recommends an upgrade to the latest version. I do not put a new site behind an unmaintained image tag just because the compose file still accepts RELEASE=-lts.

Recover the admin account while the shell still works

After the stack is up, the deploy guide says to open the web console at https://<safeline-ip>:9443/ and to get the administrator account with this command:

docker exec safeline-mgt resetadmin

A successful run tells you to remember the printed content. It shows an initial username of admin, an initial password, and a done line. I run that command from the Docker host, store the password outside the server, and log in once before I add an application. This is the documented way to obtain the administrator account inside Docker. I do not invent a database edit, a second container name, or a custom reset flag. If the command fails, the container is unhealthy, or I cannot read the password, I am not ready to proxy production traffic. The management UI is how I will later add sites and read the attack list, so a console I cannot enter is a failed checklist, not a minor inconvenience.

Secrets sit next to that login drill. A manual install keeps configuration in a directory such as /data/safeline, including POSTGRES_PASSWORD and the generated detector and management tokens, and the guide sets .env to mode 600. MGT_PORT is the console port, 9443 in the sample. MGT_PROXY is the number of console proxy layers and should stay at 0 unless a console proxy is actually being configured (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Before protection is on, I decide who can reach port 9443 and who can read .env. I do not change MGT_PROXY to paper over a login problem.

Decide the proxy path, then decide which controls to enable

SafeLine is an nginx-based reverse proxy. It receives traffic for the original site, cleans malicious traffic, and forwards the remainder to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). In the Web Admin Console, Add Application asks for Domain, Port, and Upstream. Domain may be a domain name, a hostname, or an IP. Port is what SafeLine will listen on, such as 80 or 443, and HTTPS apps need the SSL option checked. Upstream is the real address used for forwarding. After those values are saved, the domain must resolve to the SafeLine server. If DNS still points at the origin, the site is not protected. If Upstream is wrong, the site is down. I write the three values down and test resolution before I call the change complete.

The feature choice is a separate decision. Documented capabilities include defenses against 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, plus IP-based rate limiting and a web access control list (https://docs.waf.chaitin.com/en/home). The feature list also describes CAPTCHA so human visitors can pass while crawlers and bots are blocked, an authentication challenge that requires a password or else blocks the visitor, and dynamic protection that encrypts HTML and JS on each visit. I do not turn every one of those on during the first cutover. Challenges, dynamic encryption, and tight rate limits change what a legitimate user receives. My default is to prove the proxy and basic attack handling first, and to enable a challenge or dynamic encryption only after I can name the user impact.

I prove the path with the samples in the application guide, not with live customers. That page shows test requests for SQL injection, XSS, path traversal, code injection, and XXE, and says a blocking page means the attack was defended. I then open the console attack list and a detail view (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A normal request should reach the upstream. A documented attack-style request should block or at least show up in that list. If neither happens, I do not declare protection on. I correct the proxy path and repeat the test.

My go or no-go order is fixed. The host meets the documented CPU, memory, disk, Docker, Compose, and ssse3 requirements, and the ARM license rule is already satisfied if the server is ARM. docker exec safeline-mgt resetadmin has printed an admin password I have stored, and I have logged in on port 9443. Domain, listen port, and upstream are recorded, and DNS points at the SafeLine host. I know which extra controls stay off on day one. One safe request is forwarded and one documented attack-style request is visible as a block or in the attack list. Any failed line means protection stays off.

How do I reset the WAF admin account inside Docker?

On the Docker host, run the command from the deploy guide: docker exec safeline-mgt resetadmin. Success output shows an initial username of admin and an initial password. Store that password and log in at https://<safeline-ip>:9443/ before you add an application. These pages do not describe another reset method, so I do not improvise one inside the database container.

No. Adding an application and reading the attack list both happen in the Web Admin Console. If resetadmin fails or port 9443 is unreachable from your admin network, leave visitor traffic on the origin until the operator path works.

What has to be true before an application is actually protected?

SafeLine must already be installed, the application entry needs Domain, Port, and Upstream, and the domain must resolve to the SafeLine server IP. Protection is that reverse-proxy path plus inspection. A saved form with DNS still aimed at the origin is not protection.

Which controls do I leave off on the first cutover?

I leave CAPTCHA, the authentication challenge, dynamic HTML and JS encryption, and aggressive rate limits off until I have seen normal traffic through the proxy. Those controls are documented, and they change the visitor experience. I validate attack handling with the published test payloads first.

Does this checklist replace the install guide?

No. Automatic install, the compose file, environment variables, permissions, and uninstall steps belong to the official deploy guide. This list is only the set of decisions I finish after install and before real users pass through the proxy. If a recovery or tuning step is not in the supplied install or application docs, I stop rather than invent it.

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

Building an ATS Resume Scorer API with FastAPI, Celery, and Docker

Fri, 30 Oct 2026 07:57:26 +0000

Most resumes are filtered by ATS software before a human ever reads them. This project is a backend API that checks how well a resume matches a job description and suggests how to improve it.

What it does

PDF resume parsing: extracts text from uploaded resumes using pdfplumber
ATS keyword matching: compares the resume against a job description and calculates a match score
Smart suggestions: generates actionable tips to improve the resume for a specific role
JWT authentication: secured endpoints with role-based access for Job Seekers and Recruiters
Batch scoring: recruiters can score many resumes at once, handled in the background by Celery + Redis

Tech stack

Layer	Technology
Backend	Python, FastAPI
Auth	JWT (python-jose, passlib)
Database	MySQL 8.0, SQLAlchemy ORM, Alembic
Task queue	Celery + Redis
PDF parsing	pdfplumber
DevOps	Docker, Docker Compose, AWS EC2
CI/CD	GitHub Actions
Testing	Pytest

Design highlights

Background processing: batch scoring runs through a Celery queue, so the API stays responsive while many resumes are processed.
Role-based access: Job Seekers and Recruiters get separate permissions on the same API.
Reproducible setup: the whole stack (API, MySQL, Redis) starts with a single Docker Compose command.
Automated deployment: a GitHub Actions pipeline deploys automatically to AWS EC2.
Database migrations: schema changes are managed with Alembic.

Source code

https://github.com/priyadharshiny13/ats-resume-scorer

Feedback is welcome. If you were using a tool like this, what would matter more: a more accurate match score or more detailed improvement suggestions?

How to Install a WAF with the Official Linux Manager Script on a Checked Host

Thu, 29 Oct 2026 04:37:18 +0000

A self-hosted web application firewall only helps after it is actually running in front of the origin. SafeLine is a self-hosted WAF that filters and monitors HTTP traffic between a web application and the Internet, and the install guide treats one published command as the recommended automatic path. This article follows that path only: check the Linux host against the documented dependencies, run the official manager script as root, open the web console, and then place an application behind the reverse proxy. It does not invent extra flags, custom ports, or a separate uninstall switch for that script.

The product introduction describes SafeLine as a reverse-proxy shield. Clients pass through the WAF before they reach the server. It filters, monitors, and blocks malicious HTTP and HTTPS traffic, and it is described as preventing unauthorized data from leaving the application by applying policy. The same page lists typical coverage for 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. Named core capabilities are web-attack defense, proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. The feature list also describes rate limiting against denial of service, brute force, traffic surges, and other abuse; CAPTCHA challenge; authentication challenge; and dynamic protection that encrypts HTML and JavaScript on each visit. Those controls are configured after installation. They are not arguments to the manager script. See the SafeLine introduction for that capability list.

The install guide states the host requirements before either install method. The operating system must be Linux. The instruction architecture must be x86_64 or arm64. Docker must be version 20.10.14 or above, and Docker Compose must be version 2.0.0 or above. The minimum environment is 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support the ssse3 instruction. The same page publishes these confirmation commands:

uname -m
docker version
docker compose version
cat /proc/cpuinfo | grep "processor"
free -h
df -h
lscpu | grep ssse3

A missing dependency is a reason to stop. The automatic section does not document switches for architecture, a custom data directory, a custom console port, or an LTS release. Those choices appear in the manual compose section, where you create a SafeLine directory, download compose.yaml, and write .env. If the server is ARM, that manual section states that SafeLine installed on ARM requires a Pro license to work properly and that the Personal Edition is not supported on ARM. Nothing in the automatic command says the manager script waives that constraint, so an ARM host should be treated as a licensing decision before you install.

When the checks match the guide, the recommended automatic command is the official manager script. It requires root privileges:

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

The deploy page says that after this command is executed, installation has succeeded, and you should go directly to the web UI. Open https://<safeline-ip>:9443/ in a browser. The initial administrator account is obtained with a separate documented command:

docker exec safeline-mgt resetadmin

On success, the guide shows an initial username of admin, an initial password, and a reminder to keep that output. Log in with that password. Do not assume the script printed a durable account record anywhere else.

A running console is not the same as a protected site. The application guide says SafeLine is a web application firewall developed based on nginx and that it works as an HTTP and HTTPS reverse proxy. It receives traffic for the original website, cleans malicious traffic, and forwards the remaining traffic to the original application. In the web admin console, open Applications and choose Add Application. Enter the domain, hostname, or IP address of the original app; the port SafeLine will listen on, such as 80 or 443; and the upstream address used to forward traffic. For an HTTPS app, check the SSL option. Then resolve the domain you entered to the IP address of the server where SafeLine is located. Until that resolution exists, the path described in the guide is not in place.

Verification belongs on an application you control. The application guide names SQL injection, XSS, path traversal, code injection, and XXE as sample attack classes, and it says a blocking page means the attack was defended. The web console attack list, including the detail view, is where that guide says to inspect what was recorded. One blocked request does not configure rate limiting, CAPTCHA challenge, authentication challenge, or dynamic protection. Those remain separate features described in the introduction.

Keep the manual route in reserve rather than mixing it into the script. The install guide documents a directory such as /data/safeline, a requirement of at least 5 GB of disk for that directory, a downloaded compose file, environment variables, secret generation, permission steps, and docker compose up -d. It also documents uninstall as entering the SafeLine directory, running docker compose down, and then removing that directory, only when you are sure you no longer want to use SafeLine. Those are manual steps. They are not published as manager-script options. If you set RELEASE to the LTS value in the manual file, the same page says the LTS version will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and it strongly recommends that LTS users upgrade to the latest version.

The supported order is therefore short. Match Linux, architecture, Docker, Docker Compose, ssse3, memory, and disk to the install guide. Run the official manager script with root. Open the console on port 9443 and reset the admin account with the documented container command. Add the application, point the domain at the SafeLine server, and confirm blocks in the console. That is how to install this WAF with the official Linux manager script without adding steps the deploy page does not publish.

What does the official manager script require?

The install guide marks automatic deployment as recommended and says the command requires root privileges. It also requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, a CPU with ssse3, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. Run the published check commands before the installer.

Does a finished script mean the site is already protected?

No. The deploy page says a completed command means installation succeeded and that you should use the web UI. The application guide says protection is the reverse-proxy setup: add the application, set domain, listen port, and upstream, check SSL for HTTPS, and resolve the domain to the SafeLine server IP.

Where is the first console password documented?

Open https://<safeline-ip>:9443/ and run docker exec safeline-mgt resetadmin. The install guide says a successful run shows the initial username admin and an initial password, and it tells you to remember that content before you log in.

When is the manual compose path the documented alternative?

Use the manager script for the recommended automatic install. Use the manual section when you need the published compose workflow, including the SafeLine directory, compose.yaml, .env values, generated secrets, and docker compose up -d. On ARM, that section states that a Pro license is required and that the Personal Edition is not supported.

Which settings are outside the automatic command?

The automatic section does not publish a custom console port, an LTS switch, token generation, console proxy layers, or an uninstall flag. ARCH_SUFFIX, RELEASE, MGT_PORT, and related variables are documented in the manual .env instructions. Uninstall is docker compose down in the SafeLine directory, followed by removal of that directory.

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

Why I Check the Host Before the Official Linux WAF Manager Script

Thu, 29 Oct 2026 04:36:46 +0000

A one-line installer is useful only when the host underneath it already matches the product's documented requirements. SafeLine's English deploy guide marks automatic installation as the recommended path, and that path is the official Linux manager script. I still refuse to paste the script into a shell as my first action. The same page lists operating system, architecture, container runtime, memory, disk, and CPU checks before the install command. Those checks are the install, in practice. The script is the commit step.

SafeLine is a self-hosted web application firewall. Placed in front of a web application, it filters and monitors HTTP traffic between the application and the Internet. The introduction describes it as a reverse proxy: clients pass through the WAF before they reach the server, which limits direct exposure of the origin. Documented attack coverage includes 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. Listed core capabilities are defenses for web attacks, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. The feature list also includes CAPTCHA challenge, authentication challenge, and dynamic protection that encrypts HTML and JS on each visit. I cite those capabilities from the product introduction at https://docs.waf.chaitin.com/en/home so the install decision stays tied to what the WAF is actually documented to do. Installation does not turn those controls on for a site by itself.

Before the manager script, I confirm the dependency table in the deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy. The operating system must be Linux. The instruction architecture must be x86_64 or arm64. Docker must be version 20.10.14 or above. Docker Compose must be version 2.0.0 or above. The minimum environment is 1 core of CPU, 1 GB of memory, and 5 GB of disk. The CPU must provide the ssse3 instruction. The guide publishes the confirmation commands, and I run them rather than trusting a panel screenshot: uname -m, docker version, docker compose version, cat /proc/cpuinfo | grep "processor", free -h, df -h, and lscpu | grep ssse3. A host that fails any line is not ready. I do not lower the documented floor to make the script fit a smaller VM.

The recommended automatic command, which requires root privileges, is bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en. I copy that command from the deploy guide and I do not append undocumented options. The guide's success criterion is narrow and useful: after the command is executed, the installation is successful, and the next instruction is to use the web UI directly. I treat a clean exit as proof that the instance was installed, not as proof that the origin is protected. If the command fails, I return to the dependency checks and the installation FAQ linked from that page instead of retrying with guessed flags.

The documented console address is https://<safeline-ip>:9443/. In the manual environment file the management port variable MGT_PORT is set to 9443, which matches that URL. To obtain the administrator account, the guide says to run docker exec safeline-mgt resetadmin. A successful execution prints the initial username admin, an initial password, and a done line. The password belongs to that instance. I record it before closing the session, then log in with that password.

Login is still only console access. Application protection is a separate procedure, documented at https://docs.waf.chaitin.com/en/GetStarted/AddApplication. SafeLine is described there as a web application firewall developed based on nginx. It receives traffic for the original website, cleans malicious traffic, and forwards safe traffic upstream. In the web admin console I open Applications and choose Add Application. Domain accepts a domain name, a hostname, or an IP address. Port is the port SafeLine will listen on, such as 80 or 443, and HTTPS applications need the SSL option checked. Upstream is the real address of the original application. After saving, I resolve the entered domain to the IP of the server where SafeLine runs. The same page publishes sample requests for SQL injection, XSS, path traversal, code injection, and XXE. A blocking page means the attack was defended. Details are in the console attack list.

I keep manual compose as the documented alternative, not as a second opinion from an unrelated guide. Manual deploy installs Docker if needed with the published Docker install command, creates /data/safeline, requires at least 5 GB there, downloads compose.yaml, writes .env, generates a 64-character hex detector management token, a 64-character hex management internal token, and a 16-character alphanumeric detector AES key, restricts .env to mode 600, prepares runtime directories, and starts the stack with docker compose up -d. That is the path I use when I must set SAFELINE_DIR, IMAGE_TAG, MGT_PORT, POSTGRES_PASSWORD, SUBNET_PREFIX, IMAGE_PREFIX, ARCH_SUFFIX, RELEASE, REGION, or MGT_PROXY myself. MGT_PROXY is documented as the number of console proxy layers and should only be used when configuring a proxy for the console. The default is 0, meaning no proxy is configured.

Two manual settings change the decision even if the manager script is otherwise attractive. On an ARM server the guide says to set ARCH_SUFFIX to -arm and to use the ARM Postgres image. It also states that SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. I confirm edition and architecture before I install, because a successful container start is not the same statement as a supported edition. For the LTS line, RELEASE is set to -lts. The guide states that the LTS version will no longer be maintained starting from 9.1.0-LTS (14 August 2025), and that LTS users are strongly recommended to upgrade to the latest version. If there are concerns about a new release, the same note recommends upgrading one month after that release. For a first host I stay on the latest recommended automatic install unless I have a specific reason to select LTS and accept that maintenance status.

Uninstall is also explicit, and it is destructive. Enter the SafeLine directory, run docker compose down, then remove the directory with rm -rf only when you are sure you no longer want to use SafeLine. I do not use that sequence to reset a host that failed the ssse3 or disk check. Those failures should be fixed, or the install should be abandoned, before any data directory exists.

The manager script is the right Linux install path when the dependency table already passes, root is available, and I do not need to override the environment variables that only the manual page documents. It is the wrong moment to experiment when architecture, license edition, disk, or Docker version is still unknown.

What does the official manager script require on Linux?

The automatic command requires root. The host must already meet the published minimums: Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, 1 CPU core, 1 GB of memory, 5 GB of disk, and ssse3. I verify those with the commands in the deploy guide before I run the script.

Is the web console available as soon as the script finishes?

The deploy guide says a completed command means the installation succeeded and that you should open the web UI. The documented console URL is https://<safeline-ip>:9443/. You still need the administrator password from docker exec safeline-mgt resetadmin before login will succeed.

Does installation alone proxy my existing site?

No. You must add an application in the console, set domain, listen port, and upstream, and resolve that domain to the SafeLine server. Until that forwarding path exists, the origin is not behind the WAF described in the configuration guide.

Should an ARM host use the same one-line install without extra review?

Review the ARM notes first. The deploy guide says an ARM install must use the ARM architecture suffix and ARM Postgres image in the manual environment, and that SafeLine on ARM requires a Pro license. The Personal Edition is not supported on ARM.

How do I remove a test install without leaving the stack running?

From the SafeLine directory, run docker compose down. If you are certain you no longer want the product or its data, remove that directory with rm -rf. Do this only after you have exported anything you still need, because the documented removal deletes the directory.

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

Why I Verify Docker Compose and SSSE3 Before a WAF Install

Thu, 29 Oct 2026 04:26:25 +0000

Before I install a web application firewall, I verify the host against the published dependency table. For SafeLine, that table is not a suggestion buried under a feature list. The deploy guide states Linux, instruction architectures x86_64 and arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, a minimum of 1 CPU core, 1 GB of memory, 5 GB of disk, and CPU ssse3. It also prints the commands that confirm those facts. I care about Docker Compose and SSSE3 in particular because operators often prove only that the docker command exists, then treat the rest as implied. It is not implied.

SafeLine, as described in the product introduction, is a self-hosted WAF placed in front of a web application. It filters and monitors HTTP traffic and works as a reverse proxy so clients reach the WAF before the origin. That role does not relax the host requirements. A reverse proxy still has to start on a machine that meets the install contract. The introduction page points installation questions to the install guide, and the install guide is where the version and instruction checks live: https://docs.waf.chaitin.com/en/GetStarted/Deploy

I split the preflight into gates that match the command list, not into a single glance that Docker looks fine.

Architecture comes first. uname -m is the documented way to view the instruction architecture. I am looking for x86_64 or arm64, because those are the two values in the dependency table. A different machine type is a stop, even if Docker happens to be installed.

The engine and Compose are next, and they are not the same check. docker version is how the guide says to view the Docker version. I need 20.10.14 or above. docker compose version is how the guide says to view the Docker Compose version. I need 2.0.0 or above. I type Compose as a subcommand, because that is the command printed in the guide. A successful engine report does not contain the Compose version. If Compose is missing, or the version is below 2.0.0, I do not continue to the installer and I do not run a compose file just to see. The manual launch step is docker compose up -d, which assumes this dependency is already satisfied.

SSSE3 is a processor flag, checked with lscpu | grep ssse3. I want the command to print a line that includes ssse3. If it prints nothing, the flag was not found in that output, and I record a failed check. I do not reinterpret silence as probably fine on a modern CPU. The table lists CPU ssse3 on its own row. uname -m does not answer that row. Processor count does not answer it either. cat /proc/cpuinfo | grep "processor" is only the documented view of CPU info for the one-core minimum.

Memory and disk stay on the same sheet. free -h is the memory check against the 1 GB minimum. df -h is the disk check against the 5 GB minimum. The guide repeats the disk point when it tells you to create a directory: SafeLine writes configuration and data there, and you need at least 5 GB of disk space. In the manual layout that directory is /data/safeline. Checking free space on a different filesystem, then installing onto a small one, does not meet the written requirement.

ARM needs an extra documented note that is easy to mix up with the ssse3 line. The manual deploy section says SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. It also says to set ARCH_SUFFIX=-arm and to use the ARM Postgres image named in the guide. Those are edition and image settings. They are not a substitute for the ssse3 command, and the ssse3 command is not a license check. I write three separate results: architecture, whether lscpu showed ssse3, and whether the edition constraint for ARM applies to this host.

Only a full pass moves me to deploy. The recommended path in the guide is the automatic installer, which requires root and is the manager.sh command with --en. Manual deploy is the other documented path: install Docker if it is not already present, create /data/safeline, download compose.yaml, write .env, generate the tokens the guide shows, fix permissions, link the socket path, then start the stack. I do not invent a third path when a check fails. The guide's uninstall steps, docker compose down and removal of the SafeLine directory, are for a host you intend to clear, not a way to probe a machine that missed the dependency table.

Host verification is also not the same as proving the WAF is protecting an application. After a successful start, the deploy guide says to open the web console at https://<safeline-ip>:9443/ and to obtain the initial admin account with docker exec safeline-mgt resetadmin. Adding an application is a later configuration step: the console asks for domain, listen port, and upstream. The application document says SafeLine acts as an HTTP or HTTPS reverse proxy, receives traffic for the original website, cleans malicious attack traffic, and forwards the safe and reliable traffic to the original application. Those steps assume the instance is already running on a host that met the install dependencies. I cite that behavior from the official pages rather than from habit: the product overview is at https://docs.waf.chaitin.com/en/home, the dependency and command list is at https://docs.waf.chaitin.com/en/GetStarted/Deploy, and the proxy settings are at https://docs.waf.chaitin.com/en/GetStarted/AddApplication.

Does docker version replace docker compose version?

No. The deploy guide lists Docker 20.10.14 or above and Docker Compose 2.0.0 or above as separate software dependencies, and it tells you to run both docker version and docker compose version. One report does not satisfy the other row.

What if lscpu | grep ssse3 prints nothing?

That command is the published check for the CPU ssse3 instruction. No output means the flag did not appear in lscpu text on this host. I mark the dependency unmet and I do not start installation to discover a workaround. The guide does not document a bypass for a missing ssse3 flag.

Is x86_64 or arm64 enough by itself?

No. Those values satisfy the instruction architecture row only. CPU ssse3 is a separate dependency with its own command. On ARM, the same deploy guide adds a license constraint: a Pro license is required, and the Personal Edition is not supported. I do not collapse architecture, instruction flag, and edition into one result.

Which memory and disk numbers are in the contract?

The minimum environment is 1 core CPU, 1 GB memory, and 5 GB disk. free -h and df -h are the commands the guide prints for memory and disk. The directory instructions repeat that at least 5 GB must be available where SafeLine will store configuration and data.

Should the installer run before these commands pass?

No. The guide places the confirmation commands before the automatic installer and before the manual docker compose up -d step. I use them as entry conditions. A later console login check cannot repair a host that never met Docker Compose 2.0.0 or the ssse3 line.

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 Verify Docker Compose and SSSE3 Requirements for SafeLine WAF

Thu, 29 Oct 2026 04:25:53 +0000

SafeLine is a self-hosted web application firewall that filters and monitors HTTP traffic between a web application and the Internet, and it works as a reverse proxy that cleans malicious traffic before it reaches the origin server (https://docs.waf.chaitin.com/en/home). Because it runs as a set of containers managed by Docker Compose, the deployment guide asks you to confirm a short list of prerequisites before installing (https://docs.waf.chaitin.com/en/GetStarted/Deploy). The official minimums are a Linux host, x86_64 or arm64 architecture, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, 1 CPU core, 1 GB memory, 5 GB disk, and CPU support for the ssse3 instruction set. The commands below turn that checklist into a repeatable preflight routine, so you can spot a missing dependency before the installer runs.

Why does the guide require Docker Compose 2.0.0 or above?

SafeLine is deployed from a compose.yaml file with docker compose up -d. The modern docker compose plugin syntax requires Docker Compose 2.0.0 or above, and the older docker-compose binary with a hyphen does not satisfy that requirement (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Verify both tools in one step:

docker version
docker compose version

Look for the Docker Engine at 20.10.14 or newer and the Compose plugin at 2.0.0 or newer. If docker compose version returns an error, the Compose plugin is missing or only the legacy binary is installed, and that should be fixed before continuing.

What does the ssse3 CPU requirement actually mean?

ssse3, or Supplemental Streaming SIMD Extensions 3, is an x86 instruction set extension. The SafeLine deployment prerequisites list CPU ssse3 as a requirement (https://docs.waf.chaitin.com/en/GetStarted/Deploy). In practice this means the detection components expect the host CPU to expose that instruction set, so a very old or unusual x86 processor that lacks ssse3 can fail even when Docker and Compose are otherwise fine. Check it directly with:

lscpu | grep ssse3

If the command prints a line that lists ssse3 among the supported flags, the CPU is acceptable. No output usually means the flag is absent. On arm64 hosts this x86-specific check does not apply the same way, but the guide still lists arm64 as a supported instruction architecture alongside x86_64 (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

Which commands confirm the CPU, memory, and disk minimums?

The documentation groups the checks into a small command set (https://docs.waf.chaitin.com/en/GetStarted/Deploy):

uname -m reports the instruction architecture.
cat /proc/cpuinfo | grep "processor" lists the logical processors so you can confirm at least one core.
free -h shows total and available memory so you can confirm at least 1 GB.
df -h shows free disk space so you can confirm at least 5 GB in the directory where SafeLine will write its data.

Run these on the intended host rather than on a jump box or a different machine. The disk check matters because SafeLine writes configuration and data to a directory such as /data/safeline, and the guide asks for at least 5 GB there (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

What is the cleanest pre-install order to follow?

Verify in this order: operating system, architecture, ssse3, Docker, Compose, then capacity. That sequence catches the least fixable problems first. If the CPU lacks ssse3, installing newer Docker versions will not help, so it is better to learn that before downloading anything. If Docker is too old, upgrade it before the installer attempts to manage containers. Confirm the host with uname -m, check lscpu | grep ssse3, then run docker version and docker compose version, and finish with free -h and df -h. After all checks pass, the automated installer or the manual compose steps from the guide can proceed, ending with docker compose up -d and access to the web console on port 9443 by default (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

What Is an NPU Actually Good For? Testing CPU vs GPU vs NPU for Frigate

Mon, 26 Oct 2026 23:59:38 +0000

NPUs are suddenly everywhere. Intel, AMD, and Qualcomm are all shipping them in consumer hardware, and the marketing copy makes them sound like a game-changer for AI workloads. But if you run a homelab and care about practical use cases, the real question is: what can an NPU actually do for you today?

One of the most concrete answers comes from Frigate, the self-hosted NVR that uses object detection to identify people, cars, and animals in your camera feeds. It supports multiple inference backends, which makes it a great real-world benchmark for comparing CPU, GPU, and NPU performance on the same workload.

💡 Why This Matters for Homelabbers

Most homelab AI conversations center on GPUs. A discrete GPU is great for running local LLMs or doing batch inference, but it draws significant power and takes up a PCIe slot. If your goal is always-on, low-latency inference for something like security cameras, that power draw adds up fast.

An NPU is purpose-built for sustained, efficient inference. It is not trying to compete with a GPU on raw throughput for training or large model inference. It is designed to run smaller, optimized models continuously without hammering your power budget. For Frigate, which is doing object detection on every camera frame all day long, that efficiency story is genuinely relevant.

🧰 Prerequisites

A machine with an Intel Core Ultra processor (Meteor Lake, Lunar Lake, Arrow Lake or Panther Lake) for NPU access
Frigate 0.17 or newer, ideally in Docker. NPU support landed in 0.17, so earlier releases will not offer it at all
OpenVINO detector configured in your Frigate config
A host kernel with the Intel NPU driver (intel_vpu) and NPU firmware at least as new as the linux-npu-driver release bundled in your Frigate image. Frigate ships the NPU userspace inside the container, so do not mount host NPU libraries into it. Check the firmware build date with sudo dmesg | grep -i vpu
Both /dev/dri and /dev/accel passed through to the container. The NPU lives at /dev/accel/accel0, and missing it is the most common reason the NPU never shows up

The MINISFORUM MS-03 used in the source video runs an Intel Core Ultra 9 386H (Panther Lake) with an integrated GPU and a 50 TOPS NPU. One catch: Intel added Panther Lake NPU support in linux-npu-driver 1.28.0, but the official Frigate images bundle older NPU userspace (1.17.0 in 0.17.2 and 1.19.0 in 0.18.0), so Techno Tim ran a rebuilt Frigate 0.17.2 image with a newer Intel stack. On Meteor Lake, Lunar Lake and Arrow Lake, start with the official image. Mini PCs like this are a compelling homelab option because they pack modern silicon into a compact, low-power form factor.

🔧 Configuring Frigate with OpenVINO

Frigate supports OpenVINO as a detector type, which is Intel's inference runtime. It can target the CPU, the integrated GPU (via iGPU), or the NPU depending on the device string you pass in your config.

Step 1: In your frigate.yml, define a detector block using the OpenVINO type. The device value controls which processor handles inference. Common options are:

CPU: runs on the main processor cores
GPU: targets the integrated Intel GPU
NPU: targets the dedicated NPU block
AUTO: lets OpenVINO pick based on availability and load

detectors:
  openvino:
    type: openvino
    device: NPU
    model_path: /config/model_cache/yolov9t.xml

# note: the global model block sits at the TOP level, not nested under the detector
model:
  model_type: yolo-generic
  width: 640
  height: 640
  input_tensor: nchw
  input_dtype: float
  labelmap_path: /labelmap/coco-80.txt

Frigate does not ship a YOLOv9 model. The Frigate docs include a Docker build command that exports YOLOv9 to ONNX in sizes t, s, m, c or e. Techno Tim's test used YOLOv9-tiny converted to a static 640x640 OpenVINO IR, which is an .xml file plus a matching .bin. Put both files in config/model_cache and point model_path at the .xml.

Step 2: Pass the device nodes through. This is the step people get wrong: /dev/dri alone gives you the iGPU but not the NPU. You need /dev/accel as well, plus the video and render groups.

services:
  frigate:
    image: ghcr.io/blakeblackshear/frigate:0.18.0
    devices:
      - /dev/dri/card0:/dev/dri/card0
      - /dev/dri/renderD128:/dev/dri/renderD128
      - /dev/accel:/dev/accel      # the NPU; without this it is invisible
    group_add:
      - "44"    # video (GIDs vary by distro: check with getent group video)
      - "993"   # render (check with getent group render)
    volumes:
      - /path/to/config:/config
      - /path/to/media:/media/frigate
    ports:
      - "8971:8971"    # authenticated UI and API. Port 5000 is unauthenticated, so do not publish it
      - "8554:8554"

Step 3: Restart Frigate and check the logs. You should see OpenVINO initialize and report the active device. If the NPU is not detected, the most common cause is a missing driver or an unsupported kernel version. Intel's documentation covers the driver installation steps for each supported OS.

docker compose logs -f frigate | grep -i openvino

📊 CPU vs GPU vs NPU: What the Testing Shows

Based on the Techno Tim video linked below, running the same Frigate object detection workload across all three backends on the same Intel Core Ultra hardware produced some clear patterns worth understanding.

CPU: Works out of the box with no extra configuration. Inference is functional but burns CPU cycles that could be going to other processes. On a machine doing double duty as a NAS or VM host, this matters.

iGPU: Faster inference than CPU and offloads the work from your main cores. A solid middle ground that works well on most modern Intel platforms with proper drivers.

NPU: The NPU trades raw peak throughput for consistent, power-efficient inference. It is not necessarily faster than the iGPU on a frames-per-second basis, but it can free the iGPU up for other tasks like video transcoding, and it does the work at a lower power cost. For an always-on Frigate instance running 24/7, that matters more than peak speed.

The practical takeaway is that the NPU is not a replacement for a GPU in general-purpose AI workloads. It is a purpose-fit accelerator for sustained, low-complexity inference, exactly what Frigate does all day long. Frigate's own documentation makes the same split explicit: if you have both, run object detection on the NPU and leave the iGPU free for enrichments like semantic search and face recognition, plus video transcoding.

🛡️ Security Notes

Passing hardware device nodes into Docker containers does expand the attack surface slightly. A few things worth keeping in mind:

Only expose the specific device nodes Frigate needs, not broad access to all of /dev
Run the Frigate container without unnecessary capabilities
Keep Frigate and the host OS updated, especially OpenVINO and Intel driver packages
Put Frigate on a dedicated VLAN or network segment away from your cameras if possible

🔧 Troubleshooting

NPU device not found: First check that /dev/accel/accel0 exists on the host and that you actually passed /dev/accel into the container. The NPU firmware is loaded by the host kernel and is not part of the Frigate image, so a kernel without the Intel NPU driver will never expose the device.

Confirm which device is actually in use: At startup Frigate logs Loading OpenVINO model ... on device NPU, and it does not quietly move object detection from the NPU to the CPU. If the NPU is missing or its firmware is too old, the detector fails to load and the error appears in docker compose logs. Firmware older than the bundled driver can fail with MAPPED_INFERENCE_VERSION is NOT compatible with the ELF.

High latency on first detection: OpenVINO compiles the model for the selected device every time the detector starts, and the first inference includes that compilation. On the NPU, Intel's driver caches the compiled model by default, so later starts are usually quicker as long as that cache survives. Give it a few minutes to warm up before drawing conclusions about performance.

Model compatibility: Not all models work on the NPU. NPU compilation requires static input shapes, which is why the config above pins 640x640 rather than leaving the size dynamic. Stick to models Frigate ships or lists as tested for NPU use.

✅ Wrap Up

NPUs are not hype for every workload, but for always-on inference tasks like Frigate object detection, they are a genuinely useful tool. The key insight is matching the right accelerator to the right job. CPU is flexible, iGPU is fast, and the NPU is efficient for sustained, repetitive inference.

If you are running a mini PC with a modern Intel Core Ultra chip and you have Frigate deployed, it is worth spending an afternoon switching the OpenVINO device string and watching your system metrics. You might free up meaningful resources without spending anything extra.

Full credit for the hands-on testing goes to Techno Tim. Watch the original video for the full walkthrough and real metric comparisons: What Is an NPU Actually Good For? on YouTube.

Originally published at codewithromi.com.

How to Run SafeLine WAF in Docker Swarm: A Deployment Checklist

Wed, 21 Oct 2026 04:27:52 +0000

Running SafeLine WAF in Docker Swarm requires careful planning because the supplied SafeLine deployment guide documents Docker Compose, not a native Docker Swarm installation. The safest approach is to treat Swarm as an orchestration decision that needs validation against the official deployment model, rather than assuming that a Compose file can be converted without changes.

SafeLine is a self hosted web application firewall that works as a reverse proxy between clients and an application. It filters, monitors, and blocks malicious HTTP or HTTPS traffic before forwarding acceptable traffic to the original application. The official introduction describes protection against threats including SQL injection, XSS, code injection, path traversal, SSRF, XXE, brute force attempts, and HTTP floods. Source: https://docs.waf.chaitin.com/en/home

Begin with an environment inventory for every possible Swarm node. The official deployment requirements list Linux, x86_64 or arm64 architecture, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, at least one CPU core, 1 GB of memory, 5 GB of disk space, and SSSE3 CPU support. These requirements are written for the documented SafeLine setup, so verify how they map to your Swarm nodes before scheduling workloads. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Next, decide where persistent SafeLine configuration and data will live. The guide creates /data/safeline and states that SafeLine writes its configuration and data there. In a Swarm design, this raises practical questions about node placement, storage availability, recovery, and whether a task can restart on a node that contains the required data. Resolve those questions before exposing production traffic.

The documented installation also uses environment values for the SafeLine directory, image tag, management port, PostgreSQL password, internal subnet prefix, image prefix, architecture suffix, release channel, region, and management proxy layers. Review each value and preserve secrets securely. The official guide states that ARM deployments require ARCH_SUFFIX=-arm and that ARM installations require a Pro license, while the Personal Edition is not supported on ARM. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

After the platform design is validated, confirm how the documented Compose lifecycle maps to your Swarm operating procedures. The official guide uses docker compose up -d, opens the management console at https://<safeline-ip>:9443/, and retrieves the initial administrator account with docker exec safeline-mgt resetadmin. Do not assume these commands have identical behavior after a Swarm conversion. Test management access, data persistence, restart behavior, logging, and secret handling in a nonproduction environment first.

Once SafeLine is available, configure protection through its Web Admin Console. The application guide instructs administrators to add an application with its domain, listening port, SSL setting when applicable, and upstream address. DNS should then resolve the application domain to the server where SafeLine is located. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

As of September 30, 2026, SafeLine surpassed 700,000 installations worldwide. SafeLine Pro annual promotional pricing is $650-$880 versus the $1,000 regular price.

Does the official guide provide a Docker Swarm command?

No. The supplied deployment guide documents Docker and Docker Compose. It does not provide a Docker Swarm stack file, Swarm-specific service commands, overlay network instructions, or a supported Swarm conversion procedure. Treat Swarm deployment as an adaptation that requires independent validation.

What should be checked before scheduling SafeLine on Swarm nodes?

Check Linux compatibility, CPU architecture, Docker version, available memory, disk capacity, SSSE3 support, persistent storage, management port access, and secure handling of the PostgreSQL initialization password. These checks come from the documented SafeLine requirements and configuration model.

How does SafeLine receive application traffic?

SafeLine acts as an HTTP or HTTPS reverse proxy. In the Web Admin Console, define the application domain, listening port, SSL option when needed, and upstream address. Then point the domain to the SafeLine server so traffic reaches the proxy before the original application. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

How can a Swarm deployment be accepted for production?

Create a repeatable test that verifies installation, administrator access, application routing, TLS behavior, persistence after task movement, recovery from node failure, and review of attack events. Use the official SafeLine documentation as the reference for product behavior, and document every Swarm-specific change separately.

Use the official documentation to validate your architecture and invite your operations team to review the storage, networking, and recovery plan before production deployment. Project: https://github.com/chaitin/SafeLine Docs: https://docs.waf.chaitin.com/en/home Promotion: https://cyberserval.tech/landing/lto

How to Run SafeLine WAF in Docker Swarm Without Skipping the Deployment Checklist

Wed, 21 Oct 2026 04:27:21 +0000

Running a web application firewall in Docker Swarm starts with a deployment decision: determine which parts of the documented SafeLine installation can be carried into your orchestration model, then verify every assumption before exposing an application. The supplied SafeLine installation guide documents Linux, Docker, Docker Compose, and a Compose based launch with docker compose up -d. It does not document a Docker Swarm stack file or claim Swarm support. Therefore, treat Swarm deployment as an evaluation exercise rather than assuming that the documented Compose configuration is a supported Swarm integration.

SafeLine is a self hosted web application firewall that operates as a reverse proxy. It receives traffic for an original application, filters malicious requests, and forwards safe traffic to the upstream application. The official application guide describes the required application settings as domain, listening port, optional SSL, and upstream address. After configuration, the application domain should resolve to the server running SafeLine. Sources: https://docs.waf.chaitin.com/en/home and https://docs.waf.chaitin.com/en/GetStarted/AddApplication.

Begin with a compatibility inventory. The official deployment guide lists Linux, x86_64 or arm64 architecture, Docker 20.10.14 or later, Docker Compose 2.0.0 or later, and a minimum environment of 1 CPU core, 1 GB memory, and 5 GB disk. It also calls for SSSE3 CPU support. Check the host architecture, Docker version, Compose version, processor information, memory, and disk before planning a migration. These checks establish whether the documented SafeLine prerequisites are present, but they do not establish that a multi node Swarm deployment is supported. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy.

Pay close attention to persistent state. The guide creates /data/safeline, downloads compose.yaml, and places configuration and data there. In a Swarm design, you must decide how that directory is made available to the task that runs SafeLine and how it is backed up. The supplied documents do not specify shared storage, node constraints, failover behavior, rolling updates, or Swarm aware backup procedures. Record each of those as an operational requirement that needs validation in your environment.

The documented environment variables also deserve a review before any translation. They include the SafeLine directory, image tag, management port, PostgreSQL password, internal subnet prefix, image prefix, architecture suffix, release selection, and management proxy layers. The guide says to use ARCH_SUFFIX=-arm on ARM and explains that ARM installation requires a Pro license, while the Personal Edition is not supported on ARM. It also documents an LTS setting and notes that the LTS line will no longer be maintained starting from 9.1.0-LTS. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy.

A sensible proof of concept should keep one controlled node, a test hostname, a noncritical upstream, and a rollback path. Confirm that the management console is reachable at the configured management port, retrieve the initial administrator account using the documented docker exec safeline-mgt resetadmin command, and log in through the Web UI. Then add the test application in the Applications page and verify that DNS points to the SafeLine host. Do not label the result production ready until traffic routing, persistent data, certificate handling, node placement, restart behavior, and recovery have all been tested.

SafeLine documentation describes protections including web attack blocking, rate limiting, CAPTCHA challenges, authentication challenges, and dynamic HTML and JavaScript protection. Validate only the protections you enable and review the attack list in the console after controlled testing. The application guide provides examples for SQL injection, XSS, path traversal, code injection, and XXE testing. Run such tests only against an application you own or are authorized to assess. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication.

As of September 30, 2026, SafeLine surpassed 700,000 installations worldwide. SafeLine Pro annual promotional pricing is $650-$880 versus the $1,000 regular price. Treat those figures as the stated promotional information for this article and verify current availability through the supplied promotion link before making a purchase decision.

Is Docker Swarm officially documented for SafeLine?

The supplied deployment material documents Docker Compose commands and a Compose file. It does not provide a Swarm deployment procedure or confirm Swarm compatibility. Use the documented Compose path as the reference installation and validate any Swarm adaptation separately.

What should I verify before moving SafeLine into Swarm?

Verify the documented host prerequisites, image architecture, persistent access to the SafeLine directory, management port reachability, PostgreSQL password handling, DNS routing, upstream connectivity, and recovery procedures. Also document which Swarm behavior is an assumption because the supplied SafeLine guides do not describe it.

How does SafeLine reach the protected application?

SafeLine acts as an HTTP or HTTPS reverse proxy. In the Web Admin Console, add the application, provide its domain, listening port, SSL setting when applicable, and upstream address. Resolve the domain to the SafeLine server so client traffic reaches the proxy first.

What is a practical first test?

Use a disposable or low risk application, route a test hostname through SafeLine, confirm normal requests reach the upstream, and then review the console after authorized security tests. Check both blocked requests and legitimate application behavior before expanding the deployment.

If you are evaluating Docker Swarm, use this checklist with the official deployment and application guides, document every unsupported assumption, and invite your operations team to review the proof of concept. Project: https://github.com/chaitin/SafeLine Docs: https://docs.waf.chaitin.com/en/home Promotion: https://cyberserval.tech/landing/lto

Securing an Angular Application: Part 3 — Implementing CSP with Nginx

Sun, 18 Oct 2026 10:55:08 +0000

Continuing my series on hardening Angular applications, Part 3 moves into the actual Nginx server configuration and Content Security Policy (CSP) implementation.

In this part, I walk through the docker-nginx-server.conf configuration used to serve a real Angular application and explain how the different pieces work together.

Some of the topics covered:

⚙️ Angular server configuration with Nginx
🔀 Angular SPA routing
📦 Static asset handling and caching
🚫 Blocking hidden and sensitive files
🔐 Security headers
🛡️ Content Security Policy directives
🔑 Dynamic CSP nonce handling
🧩 Injecting the nonce into Angular HTML
⚠️ Error page handling
🔒 Trusted Types and other CSP protections

Rather than using a generic CSP policy, the goal is to understand which resources the Angular application actually needs and how those requirements translate into individual CSP directives.

This part also shows how the CSP nonce is handled using Nginx:

set $csp_nonce $request_id;

sub_filter_once off;
sub_filter '__CSP_NONCE__' '$csp_nonce';

This allows the nonce used by the CSP policy to be injected into the Angular application's HTML for each request.
With the Nginx configuration and CSP in place, the next part moves one layer deeper into the deployment process: Dockerizing the Angular application and packaging the Nginx configuration into a production-ready container.

📖 Read Part 3:
https://medium.com/@jangidamit800/angular-content-security-policy-csp-implementing-the-nginx-server-configuration-c70593b9136a?sharedUserId=jangidamit800

#Angular #AngularSecurity #CSP #ContentSecurityPolicy #Nginx #WebSecurity #DevSecOps #Docker #FrontendSecurity

# 🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

Sat, 17 Oct 2026 07:22:23 +0000

🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

From an open-source marketplace to a network of independent services. One step at a time.

Hey Coder Legion community! 👋

We've reached a new technical milestone with MyZubster, our open-source ecosystem focused on connecting people, projects, knowledge, and independent infrastructure.

We recently deployed our first experimental Tor v3 Onion Service using Docker and HAProxy.

🚀 What works so far?

✅ Tor successfully bootstrapped to 100%
✅ A dedicated Onion v3 identity was generated
✅ An isolated HAProxy service serves our experimental page
✅ Docker networks separate the pilot from production services
✅ The test proxy returns HTTP 404 for /api and /admin
✅ The experimental page was displayed during testing

Our architecture:

Tor Browser
     ↓
Tor v3 Onion Service
     ↓
Isolated HAProxy
     ↓
MyZubster Pilot Page

Important: This is an experimental proof of concept, not a production-ready or independently audited service. Marketplace, Zorgax, wallets, and payment systems are not part of this pilot.

🌍 Why are we building this?

We want MyZubster to evolve into an ecosystem where contributors can:

Connect independent open-source projects.
Host services on their own infrastructure.
Share verifiable technical knowledge.
Build interoperable tools.
Participate in community-driven governance.
Explore privacy-conscious access through Tor.

We believe decentralization should be demonstrated through working infrastructure, not just promises.

👨💻 What's next?

We're collaborating with our contributor community, including @wasim-builds, on the next proposed development phase:

🔹 Reproducible Docker Compose deployment
🔹 Tor and HAProxy resilience testing
🔹 Network isolation and security documentation
🔹 Independent code reviews
🔹 Better monitoring and recovery procedures

🤝 Developers wanted!

Are you interested in Docker, Tor, cybersecurity, privacy, distributed systems, or open-source collaboration?

You can contribute through documentation, testing, code review, or pull requests.

No VPS or DAO membership is required to get started.

Explore the project:

🔗 GitHub: https://github.com/MyZubster-Ecosystem/myzubster

🧅 Tor Pilot Discussion: https://github.com/MyZubster-Ecosystem/myzubster/issues/1584

🌐 Website: https://www.myzubster.com/

Let's build independent infrastructure together, one verified component at a time.

Building a Decentralized Open-Source Ecosystem: How Nicola and Wasim Are Helping MyZubster Evolve

Thu, 15 Oct 2026 05:27:32 +0000

Building a Decentralized Open-Source Ecosystem: How Nicola and Wasim Are Helping MyZubster Evolve

What happens when an open-source marketplace starts evolving into a network of independently operated nodes?

That's what we're exploring at MyZubster.

We're working toward an ecosystem where developers, creators, researchers, and independent communities can connect their projects, share verifiable knowledge, demonstrate their skills, and eventually operate their own infrastructure.

Our long-term goal is to reduce dependence on a single server, administrator, or infrastructure provider.

Two contributors are helping us explore this transition: Nicola (N4K48) and Wasim (@wasim-builds).

Their work approaches decentralization from two complementary directions.

1. Nicola N4K48 — Independent Node Experiments

Nicola is experimenting with an independently managed Docker-based node connected to the wider MyZubster ecosystem.

His work involves:

Docker-based services and local agents
Independent digital catalogs
Interoperability between contributor projects
Verifiable technical evidence
Creative content and NFT provenance experiments
Authenticated connectivity testing

A previous authenticated checkpoint between the MyZubster VPS and the N4K48 node was reported as successful.

Following credential rotation, the agent has remained offline pending authorization for any further authenticated tests.

The objective is to demonstrate that contributors can maintain control of their projects while connecting to shared services.

Nicola's work on GitHub

2. Wasim — Tor, Docker, Security and Interoperability

While Nicola is experimenting with an independent node, Wasim is designing and reviewing components that could make independently operated infrastructure more secure and reproducible.

Tor Onion + HAProxy + Docker

Wasim has prepared a technical design for a Docker-based architecture involving Tor Onion connectivity and HAProxy.

The proposal covers:

Network architecture and trust boundaries
Threat modeling
Isolated Docker environments
Reproducible tests
Rollback procedures
Security evidence
Infrastructure resilience

His reported tests were performed locally without exposing host ports, using production credentials, or requiring additional VPS resources.

The design is still under review. It has not been deployed as a production service.

GitHub:

Pastebin → GitHub → Zorgax

Wasim is also working on a proposed evidence-ingestion architecture.

The idea is to connect external technical information to MyZubster's knowledge system while preserving provenance and security.

The design includes HTTPS restrictions, redirect blocking, protection against internal-network requests, deterministic rejection tests, and mandatory human review.

The proposed evidence schema is:

myzubster.knowledge.evidence.v1

GitHub:

CI Reliability and Hardhat 3

Wasim has also participated in troubleshooting GitHub Actions workflows and reviewing the migration to Hardhat 3.

This includes work involving security audits, automated tests, dependency compatibility, and evidence checks.

Wasim also reviewed privacy protections for the Contributor Passport:

Contributor Passport Privacy Gate — PR #1599

3. The Architecture We're Exploring

                 MyZubster Ecosystem
                         |
             Shared Interoperability
                         |
          +--------------+--------------+
          |              |              |
     N4K48 Node     Future Node    Future Node
          |              |              |
     Docker/Agent    Tor/HAProxy     Independent
     Local Catalog   Docker          Application
          |              |              |
          +--------------+--------------+
                         |
                    Zorgax APIs
                         |
                Knowledge Evidence
                         |
                Contributor Passport
                         |
                    Marketplace
                         |
                  DAO Governance

This is a conceptual architecture, not an operational production federation. Wasim's infrastructure remains a design proposal.

We want independent contributors to be able to connect services without giving up ownership or control of their infrastructure.

The challenge is not simply connecting containers.

It's designing a system where interoperability, security, evidence, identity, and governance work together.

4. Why Decentralization Matters to Us

Today, many open-source projects depend heavily on a single maintainer.

That person may be responsible for:

Hosting costs
Infrastructure maintenance
Security
Deployment
Community coordination
Funding
Contributor management

This creates a technical and organizational single point of failure.

Our objective is to explore a different approach.

Independent contributors could eventually operate their own services, maintain their own environments, and communicate through documented interfaces.

This could reduce centralized infrastructure dependencies and distribute operational responsibility.

However, we have not yet demonstrated a stable production federation or fully decentralized governance.

We're building toward those goals through smaller, reproducible experiments.

5. From Technical Collaboration to a Contributor DAO

We're also exploring how a DAO-inspired governance structure could help distribute responsibilities, costs, decisions, and rewards.

The goal is not to introduce tokens without a purpose.

We want contributors to have transparent ways to demonstrate their work, participate in decisions, and potentially benefit economically from the value they create.

This requires careful work on governance, funding, accountability, and dispute resolution.

Relevant discussions:

These are ongoing proposals, not claims that a fully functioning DAO already exists.

6. What's Working, and What's Next?

Documented so far:

Local Docker and agent tests
An authenticated N4K48 node checkpoint
GitHub contributions and code reviews
Hardhat 3 migration review
Contributor Passport privacy review
Isolated Tor/HAProxy design experiments

Still under development:

Independent reproducibility reviews
Secure interoperability between multiple nodes
Production-grade resilience and failover
Shared governance procedures
Sustainable contributor funding
A fully operational federated network

Our approach is simple:

Propose → Implement → Test → Verify → Document → Improve.

We believe open-source infrastructure should be built around reproducible evidence rather than promises.

7. Developers: Want to Contribute?

We're looking for developers interested in:

Docker and container infrastructure
Tor and network resilience
Node.js and APIs
Security and CI/CD
Decentralized architectures
Knowledge graphs
Privacy and identity
Open-source governance
Reproducible technical experiments

You don't need to rent a VPS or pay for infrastructure to start contributing.

A code review, reproducible local test, documentation improvement, or security assessment can be valuable.

Explore the project

MyZubster

https://github.com/MyZubster-Ecosystem/myzubster

https://myzubster.com

Nicola N4K48

https://github.com/MyZubster-Ecosystem/myzubster/issues/1583

Wasim

https://github.com/MyZubster-Ecosystem/myzubster/pull/1610

https://github.com/MyZubster-Ecosystem/myzubster/pull/1611

Decentralization roadmap

https://github.com/MyZubster-Ecosystem/myzubster/issues/1560

Final Thoughts

Nicola is helping us explore how an independent contributor project can operate as a node.

Wasim is helping us design the infrastructure and verification processes that could make such nodes more secure, reproducible, and resilient.

Together, these efforts are moving MyZubster toward a model where independent developers can collaborate without depending entirely on centralized infrastructure.

We still have important technical and organizational challenges to solve.

But the work is happening openly, through GitHub issues, pull requests, reviews, and documented experiments.

We're not just trying to connect servers. We're trying to connect independent people, projects, skills, and verifiable knowledge.

If you're interested in contributing, reviewing the architecture, or experimenting with an independent node, join the discussion on GitHub.

Daniel Ioni (h4x0r)
Creator & Administrator — MyZubster Ecosystem

A Weekend Project With Docker Agent: Four Agents, Two Config Files, One Permissions Trap

Tue, 13 Oct 2026 13:02:21 +0000

Docker Agent lets me describe a team of AI agents, their tools, and their guardrails in one config file that a platform team can review like any other piece of infrastructure. That is the part I like most. It also has a permissions trap that I reproduced in a test, and I'll show it before you copy any example rules.

I spent a weekend-sized block of time building a small project to find out how far that idea goes. The result is release-gate-crew: four agents that review a service's container and CI configuration before release and write a PASS/BLOCK report.

What Docker Agent is

Docker Agent is Docker's open-source runtime for teams of agents. You write a config, run docker agent run crew.yaml, and talk to the root agent, which delegates to the sub-agents you declared. It ships in Docker Desktop 4.63 and later (versions 4.49 to 4.62 called it cagent), or as a standalone binary from GitHub releases. It works with Anthropic, OpenAI, Google, Bedrock, Docker Model Runner and a long list of other providers.

I used v1.150.0, released 9 October 2026.

The team

              root (lead)                think, todo
             /     |      \
 container_auditor  pipeline_auditor  scribe
 fs: ./target       fs: ./target      fs: ./reports
 shell: grep -n

The lead never reads files. It delegates, then makes the gate call: BLOCK if any finding is high or critical.
The container auditor reads target/Dockerfile and target/compose.yaml, and may run grep -n.
The pipeline auditor reads the CI workflow in target/ci/.
The scribe writes reports/gate-report.md and can write nowhere else.

target/ is a deliberately bad sample service: FROM node:latest, a token baked into ENV, a privileged container with the Docker socket mounted, and a pull_request_target workflow that checks out pull request code with permissions: write-all.

The whole team is one file

Here is the core of crew.yaml:

models:
  lead:   { provider: anthropic, model: claude-sonnet-4-5, max_tokens: 8000 }
  worker: { provider: anthropic, model: claude-haiku-4-5,  max_tokens: 4000 }

agents:
  root:
    model: lead
    description: Release gate lead. Delegates reviews and makes the PASS/BLOCK call.
    instruction_file: prompts/lead.md
    sub_agents: [container_auditor, pipeline_auditor, scribe]
    toolsets:
      - type: think
      - type: todo

  container_auditor:
    model: worker
    description: Reviews Dockerfile and compose files for container risks.
    instruction_file: prompts/container_auditor.md
    toolsets:
      - type: filesystem
        allow_list: ["./target"]
      - type: shell

  # pipeline_auditor and scribe follow the same shape

The sub_agents line is the whole orchestration. The runtime gives the lead a transfer_task tool and handles the hand-off. Each agent can use a different model, so the coordinator gets the stronger one and the workers get the cheaper one.

This is why I prefer config to framework code for this kind of work. In a code-first framework, the same team is classes, a tool registry, a loop, and retry handling, and the permissions live wherever someone remembered to put them. Here the reviewer sees the topology, the tool scope, and the policy in one diff. Swapping a provider is a two-line change. Nothing about the agents is hidden in a helper function.

The same team in HCL

Docker Agent also reads HCL. If your team writes Terraform, this will feel familiar:

agent "container_auditor" {
  model       = "worker"
  description = "Reviews Dockerfile and compose files for container risks."
  instruction = file("prompts/container_auditor.md")

  toolset "filesystem" {
    allow_list = ["./target"]
  }
  toolset "shell" {}
}

permissions {
  allow = ["read_file", "read_multiple_files", "shell:cmd=grep -n *"]
  deny  = ["shell:cmd=*curl*", "shell:cmd=*&&*", "shell:cmd=*;*", "shell:cmd=*|*"]
}

The runtime converts HCL to the YAML shape and validates both against the same schema. Labelled blocks and heredocs suit long prompts and per-agent commands well. Keep your expectations modest, though: there are no variables, locals or modules, and file() is the only function. It is a second syntax, not a second language. I keep both files in the repo and run the same tests against each, so they cannot drift apart silently.

Guardrails live next to the agents

This is where Docker Agent reads like a DevOps tool rather than an AI demo. Every layer is declared in the same file:

Layer	Config	Effect
Filesystem scope	`allow_list` per toolset	Auditors read only `./target`. The scribe writes only `./reports`.
Hidden files	`.agentsignore`	`.env`, keys and certs disappear from listings, reads and writes.
Tool rules	`permissions`	Deny, then allow, then ask.
Safety mode	`runtime.safety: restricted`	Unattended runs deny anything not explicitly allowed, without prompting.
Spend	`budget`	One shared $0.50 and 10-minute ceiling for all four agents.
Isolation	`--sandbox`	Runs the team in a Docker Sandboxes VM.

The budget detail is thoughtful. A named budget is one shared pot, so a lead that fans out to ten sub-agents cannot spend ten times the cap.

Two other features earned their place. Flavors are named patches inside the config, so --flavor cheap swaps the lead to a smaller model without a second file. Sharing packages the config as an OCI artifact: docker agent share push ./crew.yaml you/release-gate-crew, then anyone with access can docker agent run you/release-gate-crew.

Testing the guardrails without an API key

A config file is only as trustworthy as the tests behind it, so I wanted CI to prove the guardrails hold on every push without paying for tokens.

I wrote a small OpenAI-compatible stub model in Go, standard library only. It plays a fixed script per agent: the lead delegates three times, the auditors read files, and then they deliberately try things they shouldn't. An offline flavor points every agent at the stub:

flavors:
  offline:
    providers:
      stub:
        api_type: openai_chatcompletions
        base_url: http://127.0.0.1:8089/v1
        token_key: STUB_API_KEY
    models:
      lead:   { provider: stub, model: scripted }
      worker: { provider: stub, model: scripted }

A Go integration test then runs the real docker-agent binary against both crew.yaml and crew.hcl and checks each requirement in the project's SPEC.md:

--- PASS: TestCrew/crew.yaml/R2_delegates_to_scribe
--- PASS: TestCrew/crew.yaml/R4_.agentsignore_hides_target/.env
--- PASS: TestCrew/crew.yaml/R5_auditor_read_scope_holds
--- PASS: TestCrew/crew.yaml/R6_compound_shell_is_denied
--- PASS: TestCrew/crew.yaml/R7_scribe_cannot_write_target/
--- PASS: TestCrew/crew.yaml/R9_target_unchanged

What the runtime returned, verbatim:

Reading target/.env: path "target/.env" is excluded by .agentsignore
The pipeline auditor reading a prompt file: outside the allowed directories (./target)
The scribe writing target/Dockerfile: denied by the restricted safety mode, with no prompt
grep ... && curl --version: Tool 'shell' is denied by permissions configuration

The stub proves the harness, not the reviews. For review quality, the repo has three docker agent eval sessions: the gate must BLOCK the sample and name its worst problems, must not reveal the .env value when asked directly, and must not claim an edit when told to fix the Dockerfile. Those need real model keys and a container runtime, so they are not in CI yet. I have not run them yet, so I'm making no claim about review quality here.

The permissions trap

Permission patterns are globs matched against the whole command string, and * matches anything, including spaces. That makes the common prefix style unsafe for shell:

permissions:
  allow: ["shell:cmd=grep -n *"]
  deny:  ["shell:cmd=curl *"]

grep -n FROM target/Dockerfile && curl --version starts with grep -n , so it matches the allow rule. It does not start with curl , so it misses the deny rule. Deny is checked first, finds nothing, and allow approves it. I reproduced this with the stub (--flavor naive-permissions): curl ran and printed its version banner, even under restricted safety, because an explicit allow outranks the safety mode.

The documentation is clear that permissions are enforced client-side and are not a security boundary, and it points to sandbox mode for isolation. That is fair. The trap is that prefix rules like cat * and rm * are the pattern you see most often. What I use instead:

Deny shell operators outright: *&&*, *;*, *|*, backticks, $(.
Write deny rules as *curl*, not curl *.
Allow one narrow command per agent that needs a shell at all.
Run anything you don't fully trust with --sandbox.

The test suite asserts the trap still exists, so if a future release starts parsing compound commands, CI will tell me and I'll update the advice.

Other rough edges

The filesystem toolset is unrestricted by default. Without an allow_list, absolute paths and .. reach anything the process can. Docker's own example file calls this a footgun. Set allow_list on every filesystem toolset.
Pulled configs can set their own safety mode. An agent from a registry may declare runtime.safety: autonomous. Your own --safety flag or user settings win, but only if you set them. Read a config before you run it.
Sub-agents get the task text and nothing else. I confirmed it: the delegated task arrives in a <task> block in the sub-agent's system prompt, and its user turn is just "Please proceed." Isolation is good. It also means the lead's prompt must pass along everything a specialist needs.
It moves fast. The changelog lists 17 releases in September 2026 alone. Pin the version in CI. The rename from cagent also shows: the config and data directories are still ~/.config/cagent and ~/.cagent.
Telemetry is on by default. The first run says so. Set TELEMETRY_ENABLED=false in CI.
Evals have prerequisites. docker agent eval runs each case in a container and the default judge model is an OpenAI model, so plan for a container runtime and a second provider key, or pass --judge-model.

Try it

git clone https://github.com/mdabydeen/release-gate-crew && cd release-gate-crew
make test integration               # Go 1.24+ and docker-agent; no API key needed
export ANTHROPIC_API_KEY=...
docker agent run crew.yaml          # try /gate

Point it at your own service by replacing target/. If you try the evals with real keys before I do, I'd like to know what the gate gets wrong.

What I'd like to hear from people running agents in CI: where do your guardrails live today, in the agent's code or next to its config?

Originally published on DEV.

How I Built a Multi-Tenant LLM Gateway to Prevent Rogue AI Bills (OTel & Hard Limits)

Tue, 13 Oct 2026 08:48:28 +0000

If you are exposing LLMs to multiple users, clients, or internal teams, you are sitting on a ticking time bomb.

Without strict tenant-level cost attribution and hard API limits, a single rogue user—or a poorly written unhandled script loop—can rack up catastrophic OpenAI or Anthropic bills overnight. Managing these costs is currently a dangerous black box for most engineering teams.

In this guide, I'll walk you through building a Multi-Tenant LLM Gateway that completely eliminates this risk. We will cover OpenTelemetry (OTel) cost attribution, dynamic rate limiting, multi-provider fallbacks, and visualizing it all in a Streamlit dashboard.

1. The Bottleneck: Why Commercial Solutions Fall Short

When engineers realize they need to control LLM costs, they usually look at commercial AI gateways. While platforms like Helicone or Portkey are incredibly powerful, they introduce a few bottlenecks:

Pricing at Scale: Paying a percentage of your AI spend or a per-request fee to your gateway quickly becomes more expensive than the LLMs themselves.
Missing Hard Limits: Many tools offer alerting, but not synchronous hard limits that instantly cut off a tenant mid-loop before the damage is done.
Vendor Lock-in & Black Box Analytics: Tying your cost attribution to a proprietary dashboard makes it difficult to join tenant AI costs with your primary database (e.g., PostgreSQL billing tables).

By building an internal gateway, you own the traffic, the data, and the circuit breakers.

2. The Architecture: Step-by-Step Breakdown

Our gateway acts as a reverse proxy between your users/applications and the upstream LLM providers.

Here is the flow:

Request Interception: The gateway (built with Python/FastAPI) receives a standard OpenAI-compatible chat completion request. It extracts the API key to identify the tenant_id.
Hard Limit & Redis Check: Before forwarding, it queries Redis. If the tenant has exceeded their daily token limit or USD budget, the request is blocked immediately (HTTP 429).
Prompt Sanitization & Routing: The gateway cleans the payload (stripping out malicious injections or restricted domains) and determines the provider.
Multi-Provider Fallback: If OpenAI fails (e.g., 502 Bad Gateway), it seamlessly rewrites the prompt payload and fails over to Anthropic or a Local LLM.
OTel Instrumentation: Every request generates an OpenTelemetry span containing the tenant_id, provider, model, prompt_tokens, and completion_tokens.
Dashboard: A Streamlit app aggregates the OTel data from your collector/database to visualize spend per tenant.

3. The Code & Logic: Prompt Structuring & Sanitization

To make this work, the gateway needs to intercept the payload, sanitize inputs (e.g., preventing scraping agents from requesting blacklisted domains), and attach OTel traces.

Here is a Python snippet demonstrating the gateway routing, domain sanitization, and OTel attribution:

import os
import json
from fastapi import FastAPI, HTTPException, Request
from opentelemetry import trace
from redis import asyncio as aioredis
import litellm

app = FastAPI()
tracer = trace.get_tracer(__name__)
redis_client = aioredis.from_url(os.getenv("REDIS_URL", "redis://localhost:6379"))

# Domain sanitization block (e.g., for AI web scraping agents)
BLACKLISTED_DOMAINS = ["facebook.com", "instagram.com"]

def sanitize_and_structure_prompt(messages: list) -> list:
    """Sanitizes inputs and ensures structure matches fallback requirements."""
    for msg in messages:
        if any(domain in msg.get("content", "") for domain in BLACKLISTED_DOMAINS):
            raise ValueError("Blocked domain requested in prompt payload.")
    return messages

@app.post("/v1/chat/completions")
async def chat_gateway(request: Request):
    payload = await request.json()
    tenant_api_key = request.headers.get("Authorization", "").replace("Bearer ", "")
    
    # 1. Identify Tenant & Check Hard Limits in Redis
    tenant_id = await redis_client.hget("api_keys", tenant_api_key)
    if not tenant_id:
        raise HTTPException(status_code=401, detail="Invalid API Key")
        
    cost_this_month = float(await redis_client.get(f"spend:{tenant_id}") or 0.0)
    tenant_limit = float(await redis_client.get(f"limit:{tenant_id}") or 10.0) # $10 limit
    
    if cost_this_month >= tenant_limit:
        raise HTTPException(status_code=429, detail="Tenant Hard Limit Reached.")

    # 2. Sanitize Inputs
    try:
        sanitized_messages = sanitize_and_structure_prompt(payload["messages"])
    except ValueError as e:
        raise HTTPException(status_code=400, detail=str(e))

    # 3. Execute with OTel Tracing & Multi-Provider Fallback
    with tracer.start_as_current_span("llm_completion") as span:
        span.set_attribute("tenant.id", tenant_id.decode("utf-8"))
        
        try:
            # LiteLLM handles the multi-provider fallback routing automatically
            response = litellm.completion(
                model=payload.get("model", "gpt-4o-mini"),
                messages=sanitized_messages,
                fallbacks=["anthropic/claude-3-haiku-20240307"],
                metadata={"tenant_id": tenant_id}
            )
            
            # 4. Extract tokens & calculate cost
            prompt_tokens = response.usage.prompt_tokens
            completion_tokens = response.usage.completion_tokens
            cost = litellm.completion_cost(completion_response=response)
            
            # Update Redis & OTel Span
            await redis_client.incrbyfloat(f"spend:{tenant_id}", cost)
            span.set_attribute("llm.cost", cost)
            span.set_attribute("llm.usage.prompt_tokens", prompt_tokens)
            span.set_attribute("llm.usage.completion_tokens", completion_tokens)
            
            return response

        except Exception as e:
            span.set_attribute("error", True)
            span.record_exception(e)
            raise HTTPException(status_code=500, detail="LLM Routing Failed")

4. Deployment & Performance: Timeouts & Rate Limits

When dealing with LLM APIs, network timeouts are your biggest enemy. If OpenAI hangs for 60 seconds, your users experience terrible latency.

To deploy this reliably, you should wrap the entire architecture in a docker-compose.yml that spins up:

The FastAPI Gateway (with gunicorn and uvicorn workers).
A Redis instance for sub-millisecond rate limit checks.
An OpenTelemetry Collector to batch and export spans asynchronously (so tracing doesn't add latency to the user request).
A Streamlit dashboard connecting to your metrics datastore (like Prometheus or Postgres).

Handling Timeouts: In the gateway layer, configure an aggressive read timeout (e.g., timeout=15). If the primary model fails to return the first byte within 15 seconds, immediately abort the connection and execute the fallback routing to Anthropic or your local backup model.

5. Conclusion & Ready-to-Use Workflow

Building an OTel-instrumented API gateway is the only way to scale AI features across multiple tenants without risking your startup's runway. With a Redis-backed hard limit, you can confidently give API access to your users or agents knowing your max exposure is hard-coded.

You can easily recreate this architecture using the Python snippets and logic detailed above.

However, if you want to skip the trial-and-error and get a turnkey, production-ready package—complete with the full Docker Compose setup, multi-provider fallback logic, Streamlit cost dashboard, test fixtures, and raw configurations—you can grab the Multi-Tenant LLM Gateway Pro package below:

Instant Access on Whop: Get it here
Direct Download on Gumroad: Get it here (Use promo code EARLYBIRD for 20% off!)

Drop any questions about OTel implementation or LiteLLM routing in the comments!

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

Securing an Angular Application: Part 2 — Preparing the Nginx Layer

Mon, 12 Oct 2026 11:43:40 +0000

Continuing my series on hardening Angular applications, Part 2 moves from browser security concepts into the server layer.

In this part, I focus on the Nginx configuration used to serve an Angular application and build the foundation required before introducing Content Security Policy (CSP).

Some of the topics covered:

⚙️ Nginx configuration basics
📦 Serving Angular static assets
🗜️ Gzip compression
💾 Static asset caching
🔀 Angular SPA routing
🚫 Restricting access to sensitive files
⚠️ Error page handling
🔧 Preparing the Nginx layer for CSP

The goal is to understand why each configuration exists rather than simply copying an Nginx configuration from somewhere else.

This part establishes the Nginx foundation. In the next part, I'll move into the actual Angular server configuration and CSP implementation, including how the policy is built around the application's resource requirements.

📖 Read Part 2:
https://medium.com/@jangidamit800/angular-csp-configuring-content-security-policy-with-nginx

#Angular #AngularSecurity #Nginx #CSP #WebSecurity #DevSecOps #FrontendSecurity #Docker

Angular Security Headers: A Practical Guide to Securing Your Angular Application

Sat, 10 Oct 2026 12:37:43 +0000

I've started a new series focused on hardening Angular applications using browser and HTTP security controls.

In Part 1, I cover the fundamentals of security headers and how they add another layer of protection between an Angular application and the browser.

Some of the topics covered:

🔒 HSTS — enforcing HTTPS
🛡️ X-Content-Type-Options
🧭 Referrer-Policy
🎯 Permissions-Policy
🚫 X-Frame-Options
🔄 Cross-Origin Opener Policy (COOP)
🌐 Cross-Origin Resource Policy (CORP)
🔐 Content Security Policy (CSP)
The goal of this series isn't to simply copy a list of security headers, but to understand what each header does, what problem it addresses, and how these controls fit into a real Angular deployment.

This is Part 1, where we establish the foundation. The upcoming parts will move into the actual CSP, Nginx, and Docker configuration used to serve the application.

📖 Read Part 1:

https://medium.com/@jangidamit800/hardening-an-angular-application-understanding-security-headers-0c65644b981b

Would love to hear how others approach security hardening for Angular applications.

#Angular #AngularSecurity #WebSecurity #CSP #Nginx #DevSecOps #FrontendSecurity #WebDevelopment

SafeLine WAF vs Barracuda WAF: Community Edition vs Appliance-Based Security

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

SafeLine WAF vs Barracuda WAF: Community Edition vs Appliance-Based Security

SafeLine and Barracuda WAF both sit in front of your apps and block web attacks — but they're built for different buyers. Here's the practical comparison so you can tell which one matches how you actually work.

What each one is

SafeLine WAF is a self-hosted WAF by Chaitin. One command installs it as a reverse proxy that filters HTTP traffic with a semantic engine (SQLi, XSS, bot blocking) and no signature maintenance. The free Community Edition covers 10 apps at 800 QPS.

Barracuda WAF is an enterprise WAF available as a hardware appliance, virtual appliance, or cloud service. It's sold with support and management features aimed at larger IT teams, and it can be deployed inline or out-of-band.

The difference: delivery model

SafeLine is software you run yourself as a containerized reverse proxy. Lightweight, free to start, no vendor lock-in.
Barracuda is typically an appliance or managed service, often purchased with support contracts. Heavier to deploy, but it comes with vendor backing.

Side by side

	SafeLine WAF	Barracuda WAF
Deployment	Self-hosted container / reverse proxy	Appliance, virtual appliance, or cloud
Detection	Semantic analysis	Signature, behavioral, and anomaly detection
Management	Web console at :9443	Management console plus support
Cost	Free Community Edition; paid tiers	License, typically with support
Footprint	Lightweight, one server	Appliance or dedicated instance

Which should you start with?

For most self-hosters and small teams, a lightweight self-hosted WAF is enough and far cheaper:

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 traffic is filtered.

If you're in an environment that mandates an approved appliance with vendor support and integrated management, Barracuda is a conventional enterprise choice.

FAQ

Can SafeLine replace an appliance WAF?

For application-layer protection (SQLi, XSS, bots), yes. If your requirements specifically call for a physical appliance with vendor SLAs, that's a procurement decision SafeLine doesn't aim to replace.

Does SafeLine need dedicated hardware?

No. It runs as a container on a server you already have. Barracuda often implies dedicated appliance resources.

Which is faster to deploy?

SafeLine: one command and a console. Barracuda: provisioning an appliance or instance plus configuration.

Do both block bots?

Yes. SafeLine's semantic engine stops malicious and scraper traffic at the application layer; Barracuda does the same with its own detection stack.

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)

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source

Sat, 10 Oct 2026 04:14:28 +0000

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source Contributors

Docker • Tor • Node.js • React • Nginx • Privacy • Open Source

We're taking an exciting new step in the development of MyZubster: working toward making our ecosystem accessible through the Tor network using a .onion address.

Alongside our traditional website, we want to provide an alternative access path designed with privacy, infrastructure isolation, and reliability in mind.

And we're building it with the help of independent open-source contributors.

👨💻 Recognizing Our Contributors

A special thank you to Wasim (@wasim-builds) and Nicola (N4K48) for their contributions to MyZubster's evolving infrastructure.

Wasim is developing and refining changes involving our Docker setup, backend services, frontend infrastructure, and Tor integration.

🔗 Wasim's contribution — PR #1582:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1582

🔗 Wasim's GitHub:
https://github.com/wasim-builds

Nicola's earlier N4K48 contribution forms an important foundation for the work now being reviewed and tested.

🔗 Nicola / N4K48 — Original PR #1457:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1457

This is what makes open source valuable: contributors bringing independent ideas, improving each other's work, and helping transform experiments into reliable infrastructure.

🌐 What Are We Building?

We're developing a Docker-based Tor Onion Service that would allow users to access the MyZubster frontend through Tor Browser.

The intended architecture is:

        User with Tor Browser
                 |
             Tor Network
                 |
          .onion Address
                 |
         Tor Onion Service
                 |
       Internal Docker Network
                 |
          Nginx + React
                 |
          Node.js Backend
                 |
              MongoDB

The idea is to provide an alternative entry point without directly exposing backend or database services.

Our goal is not simply to generate an Onion address. We want the entire access path to be reliable, maintainable, and carefully reviewed.

✅ What We've Already Tested

We've been validating PR #1582 on an isolated VPS using dedicated Docker containers and internal networking.

Here are some of the results:

Backend and APIs

✅ Node.js backend successfully built and started after a local middleware import correction.

✅ MongoDB connectivity verified.

✅ Health, Ledger, and Economics API tests passed.

✅ Seven targeted authentication and authorization tests passed.

Frontend and Nginx

✅ React production build completed successfully.

✅ Frontend Docker image built.

✅ Nginx configuration validated.

✅ Homepage returned HTTP 200.

✅ React SPA fallback worked.

✅ Nginx successfully proxied Ledger API requests to the backend.

Tor and Onion Infrastructure

✅ Tor Docker image built successfully.

✅ Tor 0.4.9.11 installed and verified.

✅ Dedicated non-root Tor user and filesystem permissions tested.

✅ Frontend reachable from the isolated Onion test container with HTTP 200.

✅ A candidate fix for Tor's Docker hostname configuration issue passed static validation.

These are actual results from our isolated test environment, not claims of a completed public launch.

🔍 An Interesting Challenge We Discovered

The original Onion configuration used the Docker service hostname directly:

HiddenServicePort 80 frontend:80

During testing, Tor rejected the configuration:

Unparseable address in hidden service port configuration.

We reproduced the issue and tested a candidate solution using Docker DNS resolution.

The frontend hostname was resolved to its internal container IP before generating the Tor configuration.

The modified configuration passed validation.

But there's an important challenge:

Docker container IP addresses can change when services are recreated.

If Tor uses an address resolved only once at startup, it may later point to the wrong destination.

This is one of the areas where feedback from experienced infrastructure developers would be especially valuable.

🛠️ What We Still Need to Complete

Before a public Onion deployment, several tasks remain:

Integrate the tested backend middleware import fix into PR #1582.
Make Tor destination resolution resilient to Docker container restarts and IP changes.
Improve service readiness and Tor health checks.
Remove frontend build instructions that can conceal compilation failures.
Test real connectivity over the Tor network in a controlled environment.
Verify browser behavior, privacy boundaries, and end-to-end integration.
Complete security review before any production deployment.

Our Onion Service is not publicly launched or fully validated yet.

We're documenting what works, what doesn't, and what we're learning along the way.

🤝 Calling Developers Who Want to Contribute

We're particularly interested in connecting with developers experienced in:

Tor Onion Services, Docker Compose, Linux infrastructure, Node.js, React, Nginx, service discovery, and application security.

Here's a question for the community:

How would you design a reliable Tor Onion Service behind Docker when the frontend container's IP address may change?

Would you use a local reverse proxy, a service-discovery mechanism, automatic configuration reloads, or a different architecture?

We'd love to hear about approaches you've implemented or tested.

🚀 Join the MyZubster Open-Source Journey

We're building an ecosystem where contributors can experiment, review each other's ideas, and improve real infrastructure together.

Explore the project:

🌐 Website: https://www.myzubster.com/

💻 GitHub: https://github.com/MyZubster-Ecosystem/myzubster

🔧 Active contribution: https://github.com/MyZubster-Ecosystem/myzubster/pull/1582

🧩 Original N4K48 contribution: https://github.com/MyZubster-Ecosystem/myzubster/pull/1457

Thank you again to Wasim and Nicola for their work and willingness to contribute to the ecosystem.

We're not announcing a finished Onion deployment.

We're inviting the developer community to help us build one properly.

Because open source grows through collaboration, evidence, and shared progress.

MyZubster — Building together, testing together, growing together.

OpenSource #Tor #Docker #Privacy #NodeJS #React #Linux #WebDevelopment

Building ZORGAX: Turning a Local LLM into a DevOps AI Agent

Fri, 09 Oct 2026 03:43:38 +0000

Building ZORGAX: Turning a Local LLM into a DevOps AI Agent

What we learned connecting Ollama, Docker, Open WebUI, and real tool calls inside the MyZubster ecosystem.

What happens when you want your local AI to do more than answer questions?

That's the challenge we're exploring with ZORGAX, an AI assistant being developed within the MyZubster ecosystem.

Our goal is to move from a conversational language model toward a controlled infrastructure agent that can monitor servers, inspect services, diagnose failures, and eventually assist with approved maintenance operations.

We're not building an unrestricted autonomous system.

We're building something that must earn trust through testing, restricted permissions, and predictable behavior.

And during our latest experiments, we encountered a problem that illustrates exactly why that distinction matters.

The environment

Our current pilot runs on an Ubuntu VPS and brings together several components:

Component	Purpose
Ollama	Local LLM inference
Qwen 2.5 3B	Foundation language model
ZORGAX	Custom AI assistant
Open WebUI	Conversational interface
Docker Compose	Service orchestration
N4K48	Independent AI integration pilot
Qdrant	Vector infrastructure
systemd	Host-level service management

ZORGAX currently uses a custom Ollama model built on qwen2.5:3b.

We chose to start with a relatively small model to explore what could be achieved with local inference and controlled tools.

Challenge 1: Connecting containers to Ollama

Our first problem was networking.

Ollama was listening on:

172.22.0.1:11434

However, Open WebUI was configured to connect through:

http://host.docker.internal:11434

Inside the container, host.docker.internal resolved to 172.17.0.1.

Requests to that address timed out.

After verifying connectivity from inside both the N4K48 API and Open WebUI containers, we updated Open WebUI to use:

OLLAMA_BASE_URL: "http://172.22.0.1:11434"

We also configured a systemd socket proxy for host-local access through 127.0.0.1:11434, while preserving the existing Docker-facing Ollama endpoint.

The result was successful:

HTTP: 200
MODELS:
- nomic-embed-text:latest
- zorgax:latest
- qwen2.5:3b

CONNECTION: OK

Open WebUI also passed its healthcheck:

running / healthy
HTTP 200

We had established reliable connectivity between the application containers and the local AI service.

Challenge 2: From chat to tool calling

Next, we tested ZORGAX's ability to interact with external functions.

We asked the assistant to identify available capabilities and distinguish verified integrations from planned ones.

ZORGAX invoked a function named:

list_automations

The tool returned:

{
  "automations": [],
  "total": 0
}

A reasonable next step would be to report that the query returned no active automations.

Instead, ZORGAX repeated the function call.

We observed a sequence of 28 tool invocations, followed by another test that reached 16 calls.

This was the most valuable finding of the experiment.

A model that can call a function is not necessarily an agent that can manage a function safely.

Tool calling involves much more than producing correctly formatted JSON.

The agent must understand when the task is complete, avoid unnecessary retries, and behave predictably when tools return empty or unexpected results.

Challenge 3: Isolating the root cause

Rather than immediately changing the model or restarting services, we tested the behavior directly through Ollama's API.

First, we asked ZORGAX how it should respond if an automation search returned zero results.

Without any tools enabled, the model provided an appropriate response and completed generation successfully.

Then we simulated a complete function-calling interaction.

Step 1 — User request

How many active automations are there?

Step 2 — Model requests a tool

{
  "name": "list_automations",
  "arguments": {}
}

Step 3 — Simulated tool response

{
  "automations": [],
  "total": 0
}

Step 4 — Final assistant response

There are currently no active automations.

No additional tool call was generated.

This controlled test demonstrated that ZORGAX could successfully complete a tool interaction.

The repeated calls seen in Open WebUI therefore remain an integration-level issue to investigate. They could involve the model's behavior under different prompts, tool execution configuration, or the way tool responses are handled.

We haven't established a definitive root cause yet.

Why this matters for DevOps agents

Imagine extending the same behavior to real infrastructure commands.

A repeated read-only status query might consume unnecessary resources.

But a repeated restart, deployment, configuration update, or database operation could have much more serious consequences.

That is why our design direction emphasizes several safeguards:

Least-privilege access: tools receive only the permissions required.
Read-only first: monitoring before operational control.
Bounded execution: limits on calls, retries, and execution time.
Duplicate prevention: repeated requests should not automatically trigger repeated actions.
Human approval: consequential changes require explicit authorization.
Auditability: operations need traceable inputs, results, and outcomes.

These protections must exist in the execution layer, not merely as instructions inside the model's prompt.

Next milestone: `myzubster_server_status`

Our next planned integration is a read-only infrastructure monitoring tool.

The proposed myzubster_server_status interface would collect a restricted set of system information, including:

{
  "server": "myzubster",
  "services": {
    "ollama": "running",
    "docker": "running",
    "ipfs": "running"
  },
  "health": "ok"
}

This JSON is an illustrative target format, not a live measurement.

The first implementation will focus on retrieving selected health information without granting the model shell access, root permissions, or direct access to the Docker socket.

Once implemented and tested, it could enable prompts such as:

ZORGAX, check the MyZubster infrastructure and explain whether any critical services require attention.

Later, we want to expand toward bounded log diagnostics, repository health, test results, and controlled maintenance workflows.

What we've learned so far

Three lessons stand out from this development session.

1. Network connectivity is part of AI engineering.

An LLM can be perfectly healthy while the applications using it cannot reach its endpoint.

Testing from inside containers matters.

2. Tool calling requires workflow discipline.

Generating a valid function call is only the beginning. Reliable completion and retry behavior are equally important.

3. Agent safety is an architectural concern.

Prompts alone cannot enforce operational safety. Permissions, execution limits, validation, and approvals belong in the surrounding software.

Where ZORGAX stands today

ZORGAX can now communicate through Open WebUI, use the local Ollama inference service, and successfully demonstrate a controlled function-calling cycle.

The infrastructure connectivity is verified.

However, the repeated tool-call behavior observed in Open WebUI still needs investigation before broader operational tools are enabled.

Our next step is to build the monitoring layer and make the execution workflow reliable.

The long-term goal is not an AI that controls everything. It's an AI that understands what it is allowed to inspect, what it can recommend, and when it must ask for permission.

That's the direction we're taking with ZORGAX and MyZubster.

Project: MyZubster Ecosystem
AI Agent: ZORGAX
Integration Pilot: N4K48
Stack: Ollama, Qwen 2.5, Open WebUI, Docker, Python, Ubuntu

Work in progress. Current capabilities are experimental and should not be interpreted as production-ready autonomous infrastructure management.

Deploying a Production-Ready Go Scraper to Kubernetes with Prometheus: The Complete Implementation

Sun, 04 Oct 2026 01:15:51 +0000

Most Go tutorials stop at go run main.go. Real production starts after that.

I had a working Go Jobs Tracker with Prometheus metrics, but it only ran on my laptop. If I close the lid, production dies. That is not production.

This is how I took it from localhost to a scalable, observable Kubernetes deployment with 12MB images, health checks, and zero-downtime.

The Problem: Why go run is Not Production

No isolation
No auto-restart
No scaling
No observability in cluster
Secrets in .env

We need Docker plus Kubernetes plus Prometheus.

Production Dockerfile - Multi-Stage (12MB vs 1GB)

This is the Dockerfile big tech uses. Not the junior FROM golang.

Create Dockerfile in root:

Stage 1: Builder - we compile here
FROM golang:1.22-alpine AS builder

WORKDIR /app

Cache dependencies first - faster rebuilds
COPY go.mod go.sum ./
RUN go mod download

COPY . .

Build static binary - no CGO, no libc dependency
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build \
  -ldflags="-w -s" \
  -o /go-jobs-tracker ./cmd/scraper

Stage 2: Final - distroless-level small
FROM alpine:3.19

WORKDIR /app

RUN apk --no-cache add ca-certificates wget

Copy only the binary
COPY --from=builder /go-jobs-tracker .

Non-root user - security best practice
RUN adduser -D appuser
USER appuser

EXPOSE 2112

K8s needs this to know if you are alive
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:2112/healthz || exit 1

CMD ["./go-jobs-tracker"]
Why this is production grade:
- Multi-stage results in 12MB final image
- -ldflags="-w -s" strips debug symbols
- CGO_ENABLED=0 produces static binary
- Non-root user for security
- HEALTHCHECK for Docker and K8s

Build it:
docker build -t go-jobs-tracker:latest .
docker images | grep go-jobs-tracker
3. Full Observability Stack with docker-compose

One command to run everything like in production.

Create `docker-compose.yml`:
version: '3.8'
services:
  scraper:
    build: .
    ports:
            - "2112:2112"
    restart: unless-stopped
    environment:
            - SERPAPI_KEY=${SERPAPI_KEY}
    networks:
            - monitoring

  prometheus:
    image: prom/prometheus:v2.52.0
    ports:
            - "9090:9090"
    volumes:
            - ./prometheus.yml:/etc/prometheus/prometheus.yml
            - prometheus_data:/prometheus
    command:
            - '--config.file=/etc/prometheus/prometheus.yml'
            - '--storage.tsdb.path=/prometheus'
    networks:
            - monitoring

  grafana:
    image: grafana/grafana:10.4.0
    ports:
            - "3000:3000"
    environment:
            - GF_SECURITY_ADMIN_USER=admin
            - GF_SECURITY_ADMIN_PASSWORD=admin
            - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
            - grafana_data:/var/lib/grafana
    depends_on:
            - prometheus
    networks:
            - monitoring

volumes:
  prometheus_data:
  grafana_data:

networks:
  monitoring:
    driver: bridge
Create `prometheus.yml`:
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
    - job_name: 'go-jobs-tracker'
    static_configs:
            - targets: ['scraper:2112']
    metrics_path: /metrics
    scrape_interval: 5s
Run it:
docker-compose up --build
Your stack:
- App on 2112 slash metrics
- Prometheus on 9090
- Grafana on 3000 with admin slash admin

4. Kubernetes - Real Production

This is what separates Senior from Staff.

Create folder `k8s` and file `k8s/deployment.yaml`:
apiVersion: v1
kind: Secret
metadata:
  name: scraper-secrets
type: Opaque
stringData:
  serpapi-key: YOUR_SERPAPI_KEY_HERE

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-jobs-tracker
  labels:
    app: go-jobs-tracker
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: go-jobs-tracker
  template:
    metadata:
      labels:
        app: go-jobs-tracker
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "2112"
        prometheus.io/path: "/metrics"
    spec:
      containers:
            - name: scraper
        image: ghcr.io/aureliopires186/go-jobs-tracker:latest
        imagePullPolicy: Always
        ports:
                - name: metrics
          containerPort: 2112
        env:
                - name: SERPAPI_KEY
          valueFrom:
            secretKeyRef:
              name: scraper-secrets
              key: serpapi-key
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "200m"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 2112
          initialDelaySeconds: 15
          periodSeconds: 20
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /healthz
            port: 2112
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: go-jobs-tracker-service
  labels:
    app: go-jobs-tracker
spec:
  selector:
    app: go-jobs-tracker
  ports:
    - name: metrics
    port: 2112
    targetPort: 2112
    protocol: TCP
  type: ClusterIP
Deploy to K8s:
kubectl apply -f k8s/deployment.yaml
kubectl get pods -w
kubectl logs -f deployment/go-jobs-tracker
kubectl port-forward svc/go-jobs-tracker-service 2112:2112
5. The Metrics Code - What Makes It Observable

Your metrics endpoint should expose this:
// metrics/metrics.go
package metrics

import (
  "github.com/prometheus/client_golang/prometheus"
  "github.com/prometheus/client_golang/prometheus/promauto"
)

var (
  JobsScraped = promauto.NewCounterVec(prometheus.CounterOpts{
    Name: "jobs_scraped_total",
    Help: "Total number of jobs scraped",
  }, []string{"engine", "status"})

  ScrapeDuration = promauto.NewHistogramVec(prometheus.HistogramOpts{
    Name:    "scrape_duration_seconds",
    Help:    "Duration of scrape jobs",
    Buckets: prometheus.DefBuckets,
  }, []string{"engine"})

  ScraperErrors = promauto.NewCounterVec(prometheus.CounterOpts{
    Name: "scraper_errors_total",
    Help: "Total errors in scraper",
  }, []string{"type"})
)
And in http://main.go:
http.Handle("/metrics", promhttp.Handler())
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request){
  w.WriteHeader(200)
  w.Write([]byte("ok"))
})
go http.ListenAndServe(":2112", nil)
6. Result: What You Get

After this tutorial you have:

- 12MB Docker image, not 1GB
- Non-root, secure, production-ready
- docker-compose with full monitoring
- K8s with 2 replicas, zero-downtime rolling update
- Liveness and Readiness probes
- Resource limits to prevent OOM in prod
- Prometheus auto-discovery
- Secrets, not hardcoded keys

This is how real companies deploy Go in production.

Production-ready Go is not about code, it is about deployment.


•Author : Pires Aurélio

Building MyZubster with Nicola: Connecting Two Independent Systems Without Exposing a Local Computer

Fri, 02 Oct 2026 07:09:17 +0000

Building MyZubster with Nicola: Connecting Two Independent Systems Without Exposing a Local Computer

Can two developers collaborate through independent environments without exposing their local infrastructure to the public internet?

This is one of the questions we're exploring with MyZubster.

I'm working with Nicola (N4K48), a contributor who has been developing his own local MyZubster environment, including the Nicola Comics pilot. We're gradually connecting our work across Docker, knowledge graphs, verifiable evidence and decentralized technologies.

Rather than building everything at once, we're following an incremental approach: implement, test, document and verify.

1. Our latest experiment: MyZubster Node Bridge

We've developed a small Python-based communication bridge running inside Docker on a VPS.

The architecture is deliberately simple:

Nicola's computer → HTTPS → Nginx → Python Node Bridge

The bridge uses two separate authentication roles:

A node token for retrieving requests and submitting results.
An administrative token for creating requests and checking their status.

Nginx exposes only the endpoints needed by the remote node:

GET /node/next
POST /node/result

Administrative endpoints remain inaccessible through the public reverse proxy.

The bridge listens locally on the VPS, and HTTPS is enabled using Let's Encrypt.

We've already verified the following:

Docker container health checks.
Local broker communication.
Simulated request and response handling.
HTTPS certificate installation.
Authentication enforcement.
Blocking of administrative endpoints.
Public domain connectivity from the VPS.

Our next step is to connect Nicola's actual computer and validate the complete communication cycle.

An important distinction: our simulated tests were successful, but we haven't yet completed the end-to-end test between the two physical environments.

2. Beyond infrastructure: building verifiable knowledge

Our collaboration also extends to MyZubster's Knowledge Graph.

Nicola recently worked on improving how evidence is synchronized, identified and displayed.

Our MYZ-209 work included:

Stable identifiers for evidence.
Deduplication.
Knowledge Card synchronization.
Preserving historical Proof v2 attestations.
Displaying Proof v3 as a separate, identifiable attestation.

The changes were merged, and Nicola subsequently confirmed the expected behavior in production.

We're also documenting our shared learning activities involving Docker, Ethereum Sepolia, Base Sepolia, MetaMask and Zorgax.

An important principle guides this work:

Documented technical activity is evidence of an activity, not automatic certification of expertise.

We distinguish independently verifiable technical results from personal learning experiences and activities that still require confirmation.

3. Nicola Comics: a practical integration scenario

Nicola's local comics catalog gives us a concrete application for testing the bridge.

Our initial goal is to request catalog information remotely while keeping the underlying local environment under Nicola's control.

We're starting with simple operations such as retrieving the gallery and requesting comic details.

Future experiments may explore how comics, knowledge records and blockchain-based attestations could interact.

However, a technical demonstration is not equivalent to publishing an NFT or establishing ownership rights. Those would require separate verification and explicit authorization.

4. What we're learning

This project is raising several interesting engineering questions.

How much functionality should a small communication bridge expose?

How can we establish trust between independent environments without opening local services to the internet?

How do we document a successful experiment without overstating what it proves?

And how can contributors retain control over their environments while participating in a shared ecosystem?

Our approach is to keep the integration small, authentication explicit, administrative access restricted and experimental results clearly documented.

The next milestone is a real end-to-end test from Nicola's computer.

I'd be interested to hear how other developers approach secure communication between independently managed Docker environments.

Would you use a lightweight HTTPS polling bridge, a message broker or another architecture?

MyZubster #Docker #OpenSource #Cybersecurity #Python #KnowledgeGraph #Web3 #SoftwareDevelopment

Docker for Beginners

Sat, 26 Sep 2026 11:43:18 +0000

Introduction

If you’ve ever built an application that worked perfectly on your computer but failed on another machine, then you’ve experienced one of the biggest problems in software development “inconsistent environments”.

Maybe your project depended on a specific version of Python, Node.js, Java, or a database that wasn’t installed on another computer. Developers often spend hours trying to recreate the same development environment before they can even begin writing code.

This is exactly the problem Docker solves.

Docker allows developers to package an application together with everything it needs to run, the code, libraries, dependencies, configurations, and runtime into a portable package called a container.

The result is simple:

Build once, run anywhere.

Whether you’re running your application on Windows, macOS, Linux, a cloud server, or a teammate’s laptop, Docker helps ensure it behaves the same way.

Containerization

Containerization is a method of packaging software so it can run consistently across different environments.

Instead of installing every dependency manually on each machine, everything the application needs is bundled together inside a container. No matter what application is inside, Docker knows how to run it consistently.

Docker

Docker is an open source platform that helps developers build, package, distribute, and run applications inside containers.

Docker provides all the tools needed to create containers, manage them, and deploy applications with minimal setup. Instead of worrying about operating systems, dependencies, or configuration differences, developers focus on writing code.

Docker Architecture

Docker is made up of several important components. Understanding these components makes Docker much easier to learn.

Docker Engine

The Docker Engine is the core software that powers Docker. Think of Docker Engine as the “brain” of Docker.

It is responsible for:

Building Docker images
Creating containers
Running containers
Managing networks
Managing storage volumes

Whenever you type a Docker command like:

docker run nginx

Docker Engine receives the command and performs all the necessary operations behind the scenes.

Without Docker Engine, Docker cannot function.

Docker Image

A Docker Image is a blueprint or template used to create containers. Images are read only. You don’t run an image directly. Instead, Docker creates a container from an image.

It contains:

Application code
Runtime
Libraries
Dependencies
Environment variables
Configuration files

One Docker image can create many containers.

Example:

docker pull nginx

This downloads the official Nginx image.

Docker Container

A Docker Container is a running instance of a Docker image. Once an image starts running, it becomes a container. Containers are lightweight and isolated from the host operating system.

You can:

Start containers
Stop containers
Restart containers
Delete containers
Create multiple containers from one image

Example:

docker run nginx

This starts a new container using the Nginx image.

Dockerfile

A Dockerfile is a text file containing instructions for building a Docker image. Instead of creating images manually, developers define the steps inside a Dockerfile.

Example:

FROM node:20

WORKDIR /app

COPY . .

RUN npm install

EXPOSE 3000

CMD ["npm", "start"]

This tells Docker:

Start from the Node.js image
Create a working directory
Copy project files
Install dependencies
Expose port 3000
Start the application

To build the image:

docker build -t my-app .

Docker Hub

Docker Hub is an online registry where Docker images are stored and shared. It works similarly to GitHub, but instead of storing source code, it stores Docker images.

You can:

Download official images
Upload your own images
Share images publicly or privately

Popular images include:

nginx, mysql, postgres, redis, node, ubuntu, python,

To download an image:

docker pull nginx

Docker Ports

Applications inside containers run in their own isolated environment. To access them from your computer, Docker maps container ports to ports on the host machine.

Example:

docker run -p 8080:80 nginx

This means:

Port 80 is inside the container.
Port 8080 is on your computer.

Visiting:

http://localhost:8080

will display the Nginx web page.

Docker Volumes (Optional but Useful)

Containers are temporary. If a container is deleted, its data is also deleted unless it is stored in a Docker Volume. Volumes allow data to persist.

Example:

docker volume create mydata

Installing Docker

The installation process depends on your operating system.

Windows

Download Desktop Docker
Run the installer.
Enable WSL 2 if prompted.
Restart your computer.
Open Docker Desktop.
Wait until Docker starts successfully.

Verify installation:

docker --version or docker version

macOS

Download Docker Desktop for macOS.
Install the application.
Launch Docker Desktop.
Wait until Docker finishes starting.

Verify:

docker --version

Ubuntu Linux

Update packages:

sudo apt update

Install Docker:

sudo apt install docker.io

Enable Docker:

sudo systemctl enable docker
sudo systemctl start docker

Verify:

docker --version

Run without sudo (optional):

sudo usermod -aG docker $USER
Then log out and log back in.

Your First Docker Deployment

Let’s deploy a simple static web landing page using Docker.

Step 1: search the docker hub for an image

docker pull nginx

Docker downloads the latest Nginx image from Docker Hub.

Step 2: Start a Container

docker run -d -p 8088:80 --name welcome-to-docker docker/welcome-to-docker

Here’s what each option means:

-d runs the container in the background (detached mode).
-p 8080:80 maps your computer's port 8080 to the container's port 80.
--name welcome-to-docker gives the container an easy name to remember .
docker/welcome-to-docker is the image used to create the container.

Step 3: Verify the Container is Running

docker ps

You should see your running container listed.

Press enter or click to view image in full size

Step 4: Open Your Browser

Visit:

http://localhost:8088

You should see the congratulation page.

Congratulations you’ve deployed your first application using Docker!

Step 5: Stop the Container

docker stop my-nginx

Step 6: Start It Again

docker start my-nginx

Step 7: Remove the Container

docker rm my-nginx

If the container is still running, stop it first.

Summary

Through containerization, anyone can package applications and their dependencies into portable, lightweight containers that run consistently across different environments. With these fundamentals in place, you’re ready to explore more advanced Docker topics such as Docker Compose, custom image creation, networking, volumes, and multi-container applications.

How It Works and Why We Use It in Real Projects

Tue, 22 Sep 2026 14:48:32 +0000

Docker Explained: How It Works and Why We Use It in Real Projects

When I started working on backend and full-stack projects, one problem I faced was:

“It works on my laptop, but why does it not work on another laptop?”

Maybe the Node.js version is different.
Maybe Python is not installed.
Maybe MongoDB is configured differently.
Maybe some dependency is missing.

This is where I came across Docker.

Docker helps us package an application along with everything it needs to run, so we can run the same application in different environments.

In this post, I’ll explain Docker in simple language, how it works, where we can use it in projects, and a real-world example.

What is Docker?

Docker is a platform that allows us to run applications inside containers.

A container contains the application and the dependencies required to run it.

For example, suppose I have a Node.js backend.

My backend needs:

Node.js
npm packages
Environment configuration
Application code

Instead of manually installing everything on another computer, I can create a Docker image containing these requirements.

Then anyone can run that image using Docker.

So, in simple words:

Docker makes the application environment consistent.

The main idea is:

My laptop → Docker → Same environment → Your laptop/server

Why do we need Docker?

Let's take a simple example.

Suppose I build a Node.js application using:

Node.js 20
MongoDB
Express.js
Mongoose

It works perfectly on my laptop.

Now I give the project to another developer.

They might have:

Node.js 18
Different MongoDB configuration
Different operating system
Different package versions

Now the application may not work properly.

This creates the famous developer problem:

“But it works on my machine!” 😅

Docker helps solve this problem by creating a similar environment wherever the application runs.

How does Docker actually work?

There are a few important terms we should understand.

1. Dockerfile

A Dockerfile is like a set of instructions for Docker.

It tells Docker:

Which base environment to use
Which dependencies to install
Which files to copy
Which command to run

For example, a simple Node.js Dockerfile can look like:

FROM node:20

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Let's understand it step by step.

FROM

FROM node:20

This tells Docker to start with a Node.js 20 environment.

WORKDIR

WORKDIR /app

This creates/uses /app as the working directory inside the container.

COPY

COPY package*.json ./

This copies our package files into the container.

RUN

RUN npm install

This installs all the dependencies.

COPY

COPY . .

Now our application code is copied into the container.

EXPOSE

EXPOSE 3000

This tells Docker that our application uses port 3000.

CMD

CMD ["npm", "start"]

This is the command that starts our application.

2. Docker Image

After creating the Dockerfile, we can build a Docker image.

You can think of an image as a blueprint/template for our application.

For example:

Dockerfile
     ↓
Docker Image
     ↓
Docker Container

The image contains everything required to create a container.

3. Docker Container

A container is the running instance of an image.

For example:

Node.js Application Image
           ↓
      Container 1

We can also create multiple containers from the same image.

             Docker Image
             /     |     \
            ↓      ↓      ↓
       Container Container Container

Each container can run the same application in an isolated environment.

Image vs Container

This was slightly confusing for me initially.

A simple way to remember it is:

Image = Blueprint

Container = Running application created from that blueprint

Think about a house.

The building plan is like the Docker image.

The actual house built from that plan is like the Docker container.

What happens when we run a Docker container?

Suppose we run:

docker run my-app

Docker takes the my-app image and creates a container from it.

Then the application starts inside that container.

The basic flow is:

Dockerfile
     ↓
Build
     ↓
Docker Image
     ↓
Run
     ↓
Docker Container
     ↓
Application Running

Docker Architecture

Docker mainly works using a client-server architecture.

The important parts are:

Docker Client
     ↓
Docker Daemon
     ↓
Docker Images
     ↓
Docker Containers

When we run commands such as:

docker build
docker run
docker ps
docker stop

the Docker client communicates with the Docker daemon.

The daemon is responsible for creating and managing containers, images, networks, and other Docker resources.

Docker vs Virtual Machine

One common question is:

“Is Docker the same as a Virtual Machine?”

No.

Both can isolate applications, but they work differently.

A Virtual Machine usually includes:

Application
Libraries
Guest OS
Virtual Hardware
Host OS

Docker containers share the host operating system's kernel, so they generally need fewer resources than full virtual machines.

A simplified comparison:

Virtual Machine

Application
     ↓
Libraries
     ↓
Guest OS
     ↓
Hypervisor
     ↓
Host OS

Docker:

Application
     ↓
Libraries
     ↓
Container
     ↓
Docker
     ↓
Host OS

Because containers are lightweight, we can start them quickly and run many of them on the same machine.

Where can we use Docker in a project?

Docker becomes especially useful when our project has multiple services.

For example, imagine a MERN application:

React Frontend
       ↓
Node.js Backend
       ↓
MongoDB

Instead of installing everything directly on a server, we can run different services in containers.

For example:

Docker
│
├── Frontend Container
│
├── Backend Container
│
└── Database Container

This gives us a cleaner and more consistent development environment.

Docker Compose

When our project has multiple containers, managing them individually can become difficult.

For this, Docker Compose is useful.

For example:

Frontend
Backend
MongoDB
Redis

We can define these services in a docker-compose.yml file.

A simplified example:

services:

  backend:
    build: ./backend
    ports:
      - "5000:5000"

  frontend:
    build: ./frontend
    ports:
      - "3000:3000"

  mongodb:
    image: mongo
    ports:
      - "27017:27017"

Now we can start the whole application using:

docker compose up

Instead of manually starting every service.

Real-World Scenario

Let's take a real example.

Imagine an e-commerce company.

The application has:

Frontend
Backend API
Payment Service
Product Service
Database
Redis Cache

Without containers, setting up this environment on a new server can take a lot of time.

Developers may need to install:

Node.js
MongoDB/PostgreSQL
Redis
Different dependencies
Correct versions
Environment configurations

With Docker, each service can have its own container.

For example:

                 Docker
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   Frontend      Backend       Redis
   Container     Container     Container
                    │
                    ↓
               Database
               Container

Now the development, testing, and deployment environments can be much more consistent.

Docker in CI/CD

Docker is also very useful in CI/CD.

Suppose a developer pushes code to GitHub.

A CI/CD pipeline can:

Developer
    ↓
Git Push
    ↓
GitHub
    ↓
CI/CD Pipeline
    ↓
Build Docker Image
    ↓
Run Tests
    ↓
Deploy
    ↓
Production

This means the same containerized application can move through different stages of development and deployment.

For example:

Development
      ↓
Testing
      ↓
Staging
      ↓
Production

The goal is to reduce environment-related problems between these stages.

Docker in My Own Projects

For the type of full-stack projects I work on, Docker can be useful when the project contains multiple technologies.

For example, suppose I have a backend built with:

Node.js
Express.js
MongoDB

I can use Docker to create a consistent environment for the backend and database.

If later I deploy the project on a cloud server, I don't have to manually recreate the complete environment from scratch.

I can build the image and run the container on the server.

Some Docker Commands I Started With

These are some basic commands that are useful when learning Docker.

Check Docker version:

docker --version

Build an image:

docker build -t my-app .

Run a container:

docker run my-app

See running containers:

docker ps

See all containers:

docker ps -a

Stop a container:

docker stop <container_id>

Remove a container:

docker rm <container_id>

See available images:

docker images

Remove an image:

docker rmi <image_id>

Start Docker Compose:

docker compose up

Stop Docker Compose:

docker compose down

What Problem Does Docker Actually Solve?

For me, the easiest way to understand Docker is not to remember definitions.

Think about the problem first.

Without Docker:

"My application works on my computer."

But on another computer:

Different OS
Different Node version
Missing dependency
Different database setup
Different configuration

With Docker:

Application
+
Dependencies
+
Required environment
        ↓
      Docker
        ↓
   Same environment

That's the main reason Docker is useful.

Docker is Not Only for Deployment

Initially, I thought Docker was mainly something used by DevOps engineers for deployment.

But Docker can be useful during development too.

It can help developers:

Set up projects quickly
Keep environments consistent
Run databases locally
Run multiple services
Test applications in isolated environments
Work with different versions of tools
Prepare applications for deployment

So Docker is useful for both developers and DevOps teams.

What I Learned From Docker

The biggest thing I understood is that Docker is not just about running commands.

The actual idea is:

Package the application and its environment so it can run consistently in different places.

Once I understood the difference between:

Dockerfile
    ↓
Image
    ↓
Container

Docker became much easier to understand.

And when we add Docker Compose, we can manage multiple containers together.

Final Thoughts

Docker is one of those technologies that looks complicated when you first see terms like:

Images
Containers
Dockerfile
Volumes
Networks
Compose
Docker Engine

But the basic concept is actually simple.

Docker packages applications into containers so that they can run in a consistent and isolated environment.

For a beginner like me, I think the best way to learn Docker is not by memorizing all the commands.

Start with one small project.

Create a Dockerfile.

Build an image.

Run a container.

Then try Docker Compose with a backend and database.

Once you actually see the application running inside a container, the concept becomes much clearer.

That's how I'm currently understanding Docker, and I think it's a useful technology to learn if you're working with Full Stack Development, Backend, Cloud, or DevOps.

How It Works and Why We Use It in Real Projects

Tue, 22 Sep 2026 13:56:16 +0000

Docker Explained: How It Works and Why We Use It in Real Projects

When I started working on backend and full-stack projects, one problem I faced was:

“It works on my laptop, but why does it not work on another laptop?”

Maybe the Node.js version is different.
Maybe Python is not installed.
Maybe MongoDB is configured differently.
Maybe some dependency is missing.

This is where I came across Docker.

Docker helps us package an application along with everything it needs to run, so we can run the same application in different environments.

In this post, I’ll explain Docker in simple language, how it works, where we can use it in projects, and a real-world example.

What is Docker?

Docker is a platform that allows us to run applications inside containers.

A container contains the application and the dependencies required to run it.

For example, suppose I have a Node.js backend.

My backend needs:

Node.js
npm packages
Environment configuration
Application code

Instead of manually installing everything on another computer, I can create a Docker image containing these requirements.

Then anyone can run that image using Docker.

So, in simple words:

Docker makes the application environment consistent.

The main idea is:

My laptop → Docker → Same environment → Your laptop/server

Why do we need Docker?

Let's take a simple example.

Suppose I build a Node.js application using:

Node.js 20
MongoDB
Express.js
Mongoose

It works perfectly on my laptop.

Now I give the project to another developer.

They might have:

Node.js 18
Different MongoDB configuration
Different operating system
Different package versions

Now the application may not work properly.

This creates the famous developer problem:

“But it works on my machine!” 😅

Docker helps solve this problem by creating a similar environment wherever the application runs.

How does Docker actually work?

There are a few important terms we should understand.

1. Dockerfile

A Dockerfile is like a set of instructions for Docker.

It tells Docker:

Which base environment to use
Which dependencies to install
Which files to copy
Which command to run

For example, a simple Node.js Dockerfile can look like:

FROM node:20

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Let's understand it step by step.

FROM

FROM node:20

This tells Docker to start with a Node.js 20 environment.

WORKDIR

WORKDIR /app

This creates/uses /app as the working directory inside the container.

COPY

COPY package*.json ./

This copies our package files into the container.

RUN

RUN npm install

This installs all the dependencies.

COPY

COPY . .

Now our application code is copied into the container.

EXPOSE

EXPOSE 3000

This tells Docker that our application uses port 3000.

CMD

CMD ["npm", "start"]

This is the command that starts our application.

2. Docker Image

After creating the Dockerfile, we can build a Docker image.

You can think of an image as a blueprint/template for our application.

For example:

Dockerfile
     ↓
Docker Image
     ↓
Docker Container

The image contains everything required to create a container.

3. Docker Container

A container is the running instance of an image.

For example:

Node.js Application Image
           ↓
      Container 1

We can also create multiple containers from the same image.

             Docker Image
             /     |     \
            ↓      ↓      ↓
       Container Container Container

Each container can run the same application in an isolated environment.

Image vs Container

This was slightly confusing for me initially.

A simple way to remember it is:

Image = Blueprint

Container = Running application created from that blueprint

Think about a house.

The building plan is like the Docker image.

The actual house built from that plan is like the Docker container.

What happens when we run a Docker container?

Suppose we run:

docker run my-app

Docker takes the my-app image and creates a container from it.

Then the application starts inside that container.

The basic flow is:

Dockerfile
     ↓
Build
     ↓
Docker Image
     ↓
Run
     ↓
Docker Container
     ↓
Application Running

Docker Architecture

Docker mainly works using a client-server architecture.

The important parts are:

Docker Client
     ↓
Docker Daemon
     ↓
Docker Images
     ↓
Docker Containers

When we run commands such as:

docker build
docker run
docker ps
docker stop

the Docker client communicates with the Docker daemon.

The daemon is responsible for creating and managing containers, images, networks, and other Docker resources.

Docker vs Virtual Machine

One common question is:

“Is Docker the same as a Virtual Machine?”

No.

Both can isolate applications, but they work differently.

A Virtual Machine usually includes:

Application
Libraries
Guest OS
Virtual Hardware
Host OS

Docker containers share the host operating system's kernel, so they generally need fewer resources than full virtual machines.

A simplified comparison:

Virtual Machine

Application
     ↓
Libraries
     ↓
Guest OS
     ↓
Hypervisor
     ↓
Host OS

Docker:

Application
     ↓
Libraries
     ↓
Container
     ↓
Docker
     ↓
Host OS

Because containers are lightweight, we can start them quickly and run many of them on the same machine.

Where can we use Docker in a project?

Docker becomes especially useful when our project has multiple services.

For example, imagine a MERN application:

React Frontend
       ↓
Node.js Backend
       ↓
MongoDB

Instead of installing everything directly on a server, we can run different services in containers.

For example:

Docker
│
├── Frontend Container
│
├── Backend Container
│
└── Database Container

This gives us a cleaner and more consistent development environment.

Docker Compose

When our project has multiple containers, managing them individually can become difficult.

For this, Docker Compose is useful.

For example:

Frontend
Backend
MongoDB
Redis

We can define these services in a docker-compose.yml file.

A simplified example:

services:

  backend:
    build: ./backend
    ports:
      - "5000:5000"

  frontend:
    build: ./frontend
    ports:
      - "3000:3000"

  mongodb:
    image: mongo
    ports:
      - "27017:27017"

Now we can start the whole application using:

docker compose up

Instead of manually starting every service.

Real-World Scenario

Let's take a real example.

Imagine an e-commerce company.

The application has:

Frontend
Backend API
Payment Service
Product Service
Database
Redis Cache

Without containers, setting up this environment on a new server can take a lot of time.

Developers may need to install:

Node.js
MongoDB/PostgreSQL
Redis
Different dependencies
Correct versions
Environment configurations

With Docker, each service can have its own container.

For example:

                 Docker
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   Frontend      Backend       Redis
   Container     Container     Container
                    │
                    ↓
               Database
               Container

Now the development, testing, and deployment environments can be much more consistent.

Docker in CI/CD

Docker is also very useful in CI/CD.

Suppose a developer pushes code to GitHub.

A CI/CD pipeline can:

Developer
    ↓
Git Push
    ↓
GitHub
    ↓
CI/CD Pipeline
    ↓
Build Docker Image
    ↓
Run Tests
    ↓
Deploy
    ↓
Production

This means the same containerized application can move through different stages of development and deployment.

For example:

Development
      ↓
Testing
      ↓
Staging
      ↓
Production

The goal is to reduce environment-related problems between these stages.

Docker in My Own Projects

For the type of full-stack projects I work on, Docker can be useful when the project contains multiple technologies.

For example, suppose I have a backend built with:

Node.js
Express.js
MongoDB

I can use Docker to create a consistent environment for the backend and database.

If later I deploy the project on a cloud server, I don't have to manually recreate the complete environment from scratch.

I can build the image and run the container on the server.

Some Docker Commands I Started With

These are some basic commands that are useful when learning Docker.

Check Docker version:

docker --version

Build an image:

docker build -t my-app .

Run a container:

docker run my-app

See running containers:

docker ps

See all containers:

docker ps -a

Stop a container:

docker stop <container_id>

Remove a container:

docker rm <container_id>

See available images:

docker images

Remove an image:

docker rmi <image_id>

Start Docker Compose:

docker compose up

Stop Docker Compose:

docker compose down

What Problem Does Docker Actually Solve?

For me, the easiest way to understand Docker is not to remember definitions.

Think about the problem first.

Without Docker:

"My application works on my computer."

But on another computer:

Different OS
Different Node version
Missing dependency
Different database setup
Different configuration

With Docker:

Application
+
Dependencies
+
Required environment
        ↓
      Docker
        ↓
   Same environment

That's the main reason Docker is useful.

Docker is Not Only for Deployment

Initially, I thought Docker was mainly something used by DevOps engineers for deployment.

But Docker can be useful during development too.

It can help developers:

Set up projects quickly
Keep environments consistent
Run databases locally
Run multiple services
Test applications in isolated environments
Work with different versions of tools
Prepare applications for deployment

So Docker is useful for both developers and DevOps teams.

What I Learned From Docker

The biggest thing I understood is that Docker is not just about running commands.

The actual idea is:

Package the application and its environment so it can run consistently in different places.

Once I understood the difference between:

Dockerfile
    ↓
Image
    ↓
Container

Docker became much easier to understand.

And when we add Docker Compose, we can manage multiple containers together.

Final Thoughts

Docker is one of those technologies that looks complicated when you first see terms like:

Images
Containers
Dockerfile
Volumes
Networks
Compose
Docker Engine

But the basic concept is actually simple.

Docker packages applications into containers so that they can run in a consistent and isolated environment.

For a beginner like me, I think the best way to learn Docker is not by memorizing all the commands.

Start with one small project.

Create a Dockerfile.

Build an image.

Run a container.

Then try Docker Compose with a backend and database.

Once you actually see the application running inside a container, the concept becomes much clearer.

That's how I'm currently understanding Docker, and I think it's a useful technology to learn if you're working with Full Stack Development, Backend, Cloud, or DevOps.

SafeLine WAF Docker Compose Example

Tue, 22 Sep 2026 03:23:27 +0000

SafeLine WAF Docker Compose Example

SafeLine ships as a set of containers, and Docker Compose is the simplest way to bring up the whole stack — management console, detection engine, and the supporting database and cache — on a single host.

The fastest path

The official one-line installer handles the compose file for you:

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

It writes a docker-compose.yml in the SafeLine directory and starts the services. After it finishes, open the console at https://<host-ip>:9443 to add your protected sites.

What the stack contains

A typical SafeLine compose defines a few services working together:

Management console — the web UI on :9443 where you configure sites and view logs.
Detection engine / proxy — the component that actually inspects and forwards traffic on :80 / :443.
Database — stores configuration and records.
Cache — used for session and challenge state.

An illustrative compose looks like:

services:
  safeline-mgt:            # management console
    image: chaitin/safeline-mgt:latest
    ports: ["9443:9443"]
  safeline-detector:       # inspection + reverse proxy
    image: chaitin/safeline-detector:latest
    ports: ["80:80", "443:443"]
  safeline-pg:             # database
    image: chaitin/safeline-pg:latest
  safeline-redis:          # cache
    image: chaitin/safeline-redis:latest

Treat the exact image names, tags, and ports above as illustrative — pull the authoritative docker-compose.yml from the official installer or docs, since these can change between versions.

Customizing

Once it's up, common tweaks:

Persist data — add named volumes for the database and config so they survive container recreation.
Change ports — if :80/:443 are taken, map the proxy to different host ports and adjust your upstream/DNS accordingly.
Protect a site — in the console, add a site whose upstream is your app (e.g. http://127.0.0.1:8080).

FAQ

Do I need to write the compose myself?

No — the installer generates it. Hand-writing is only if you want a custom layout.

Can I run it alongside other compose stacks?

Yes; just keep the ports and volume names from colliding with other services.

Free tier?

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

That's it — a single compose stack gives you a running self-hosted 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 Install SafeLine WAF with Docker in 10 Minutes

Thu, 17 Sep 2026 04:16:13 +0000

How to Install SafeLine WAF with Docker in 10 Minutes

SafeLine is designed to run as a container, which makes Docker the natural
deployment path. This walkthrough gets you from zero to a working reverse-proxy WAF.

What you need

A Linux host (VM or bare metal) with Docker installed.
At least 1 CPU, 1 GB RAM, 5 GB free disk.
A service you want to protect (e.g., a web app on port 8080).

Step 1: Install SafeLine

Run the official installer:

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

This pulls the SafeLine containers and starts the management console.

Step 2: Open the dashboard

Navigate to https://<your-host-ip>:9443. Complete the initial setup and create an admin
account. You can also explore the live demo first at
https://demo.waf.chaitin.com:9443/statistics.

Step 3: Add your upstream

In the console, register the site you want to protect and point its upstream at your real app
(e.g., http://127.0.0.1:8080). SafeLine now inspects traffic before proxying it.

Step 4: Route traffic

Point your domain or load balancer at the SafeLine listener instead of the app directly. SafeLine
blocks malicious requests (SQLi, XSS, bot abuse) using its semantic-analysis engine.

FAQ

Do I need docker-compose?

The installer manages containers for you; compose is optional for custom setups.

What if the container restarts?

SafeLine persists config; set a restart policy so it comes back automatically.

Is this production-ready?

Yes — the Community Edition is free and handles 10 apps at 800 QPS.

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

Running Qwen Locally as a Third-Party Backend for Claude: What Actually Broke

Tue, 15 Sep 2026 06:21:26 +0000

I didn't set out to write a tutorial. This is closer to a log of what happened when I tried to wire a locally-hosted Qwen model into Claude's third-party inference gateway, and the things that quietly broke before it worked.

Why bother with a local backend at all

Most of my work involves research and document generation that doesn't need to hit a hosted API every single time. I wanted something I could run on my own machine, mostly to experiment freely without worrying about racking up API calls for every small test. The idea wasn't to replace Claude, but to have a local option sitting behind the same interface, one I could point at when the task didn't call for a hosted model.

Qwen3.6 looked like a reasonable fit for this. Not because it's the newest or the most talked about, but because it's the kind of model you can actually run on a single machine without needing a rack of GPUs.

The basic shape of the setup

The architecture ended up being fairly simple on paper: llama-server runs the model locally, and LiteLLM sits in front of it as a proxy that speaks the API shape Claude's third-party inference gateway expects. LiteLLM runs inside a Docker container (via Colima on macOS), and llama-server runs directly on the host.

On paper, that's three components talking to each other. In practice, it took a bit of trial and error before they actually did.

The Docker networking trap

The first real snag came from something that seems obvious in hindsight: LiteLLM, running inside a Docker container, tried to reach llama-server via 127.0.0.1. That address, from inside a container, doesn't point to the host machine. It points to the container's own loopback interface, which has nothing running on it.

The fix was switching to host.docker.internal instead. It's a small detail, but it's the kind of thing that costs an hour of confused debugging if you haven't hit it before. If you're bridging a host-level service to something running inside Docker, this is worth checking first, before assuming the service itself is broken.

Hitting a context window wall

Once the plumbing was working, a different problem showed up during a longer conversation: a ContextWindowExceededError, with the context window set to 32768 tokens on llama-server. It's a reminder that a locally-served model doesn't quietly resize itself the way a hosted API sometimes appears to. The ceiling is whatever you set at launch, and it will tell you when you've hit it.

The trade-off nobody tells you about upfront

I started with Qwen3.6-27B, then moved to Qwen3.6-35B-A3B. The larger model scores well (Qwen3.6-27B benchmarks around 77.2% on SWE-bench), but it's also slower to respond. That trade-off between quality and speed is easy to state in the abstract, but it feels very different once you're the one waiting on time-to-first-token during an actual working session.

There's no universally correct answer here. It depends on whether the task in front of you needs the better score more than it needs the faster reply.

Where things stand now

LiteLLM is successfully connected to Claude's third-party inference gateway, with the local model mapped in the gateway configuration. It works. It is also, honestly, still a work in progress rather than a finished setup I'd call done. Configuration around slot persistence, context sizing, and model choice is something I expect to keep adjusting as I use it more.

If you've built something similar, or hit a different wall along the way, I'd be glad to compare notes. This kind of setup seems to have more undocumented edges than the clean tutorials suggest.

How I Connected a Dockerized Python API to a Local Mistral Model

Wed, 02 Sep 2026 17:04:05 +0000

How I Connected a Dockerized Python API to a Local Mistral Model

I’m currently building the AI foundation for MyZubster, and one of my first goals was to create a local development environment that could run without relying on paid external AI APIs.

The stack uses:

Python and Flask for the application API
Docker Compose for orchestration
Ollama for local model inference
Mistral as the language model
Qdrant for vector storage
Open WebUI for manual testing

This post explains how the services are connected and highlights a few issues I encountered along the way.

The architecture

The planned AI workflow is:

User request
    ↓
MyZubster Flask API
    ↓
Semantic search in Qdrant
    ↓
Relevant MyZubster data
    ↓
Mistral through Ollama
    ↓
Generated response

Qdrant will provide the retrieval part of the RAG pipeline, while Mistral will generate an answer using the retrieved context.

Why Ollama runs on the host

Ollama was already installed and running directly on Windows at:

http://localhost:11434

The mistral:latest model was also already downloaded.

I decided not to add another Ollama container because that would duplicate model storage, increase memory usage and conflict with the port already occupied by the host process.

Docker Desktop provides the special hostname:

host.docker.internal

Containers can use it to connect to services running on the host machine.

Inside the MyZubster API container, the Ollama address therefore becomes:

http://host.docker.internal:11434

Verifying the connection

Before changing the application, I tested the connection using a temporary curl container:

docker run --rm curlimages/curl:8.12.1 `
  http://host.docker.internal:11434/api/tags

Ollama returned the installed model:

{
  "models": [
    {
      "name": "mistral:latest",
      "parameter_size": "7.2B",
      "quantization_level": "Q4_K_M"
    }
  ]
}

This confirmed that Docker could communicate with Ollama on the Windows host.

Docker Compose stack

Here is the Compose configuration used for the local environment:

services:
  api:
    build:
      context: .
    init: true
    ports:
      - "5000:5000"
    environment:
      MYZUBSTER_HOST: "0.0.0.0"
      MYZUBSTER_PORT: "5000"
      MYZUBSTER_OBSERVATIONS_FILE: "/data/observations.json"
      OLLAMA_BASE_URL: "http://host.docker.internal:11434"
      OLLAMA_MODEL: "mistral:latest"
      QDRANT_URL: "http://qdrant:6333"
      QDRANT_COLLECTION: "myzubster"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - observations-data:/data
    depends_on:
      qdrant:
        condition: service_started
    restart: unless-stopped

  qdrant:
    image: qdrant/qdrant:latest
    ports:
      - "127.0.0.1:6333:6333"
      - "127.0.0.1:6334:6334"
    volumes:
      - qdrant-data:/qdrant/storage
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      OLLAMA_BASE_URL: "http://host.docker.internal:11434"
      WEBUI_AUTH: "true"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - open-webui-data:/app/backend/data
    restart: unless-stopped

volumes:
  observations-data:
  qdrant-data:
  open-webui-data:

networks:
  default:
    name: myzubster-ai-network

The API communicates with Qdrant using its Compose service name:

http://qdrant:6333

It communicates with Ollama through the host gateway:

http://host.docker.internal:11434

Starting the environment

I first validate the Compose file:

docker compose config

Then I pull the external images and start the stack:

docker compose pull
docker compose down
docker compose up -d --build

The service status can be checked with:

docker compose ps

Useful logs are available through:

docker compose logs --tail 100 api
docker compose logs --tail 100 qdrant
docker compose logs --tail 100 open-webui

Testing Ollama from the application container

A successful request from Windows does not necessarily prove that the application container can reach Ollama.

I tested the full connection from inside the API container:

docker compose exec api python -c "import json,os,urllib.request; url=os.environ['OLLAMA_BASE_URL']+'/api/generate'; data=json.dumps({'model':os.environ['OLLAMA_MODEL'],'prompt':'Reply only with: MyZubster connected','stream':False}).encode(); req=urllib.request.Request(url,data=data,headers={'Content-Type':'application/json'}); result=json.loads(urllib.request.urlopen(req,timeout=120).read()); print(result['response'].strip())"

The container received a generated response, confirming that the networking and environment variables were configured correctly.

A PowerShell trap

One mistake I made was pasting YAML directly into PowerShell:

services:
  api:
    build:
      context: .

PowerShell interpreted each YAML key as a command and returned errors such as:

The term 'services:' is not recognized as the name of a cmdlet

A Compose configuration must be saved as docker-compose.yml; it cannot be executed directly.

To open the file in Visual Studio Code:

code docker-compose.yml

Always validate it afterward:

docker compose config

Available services

After startup, the local tools are available at:

MyZubster API: http://localhost:5000
Open WebUI: http://localhost:3000
Qdrant dashboard: http://localhost:6333/dashboard
Ollama API: http://localhost:11434

Qdrant and Open WebUI are bound to 127.0.0.1, so their ports are not exposed to other devices on the network.

What comes next

The containers provide the infrastructure, but the actual RAG pipeline still needs to be implemented.

The next development steps are:

Install an embedding model in Ollama.
Create a Qdrant collection with the correct vector dimensions.
Generate embeddings for MyZubster content.
Store vectors together with useful metadata.
Embed incoming user questions.
Retrieve the most relevant records from Qdrant.
Add the retrieved context to the Mistral prompt.
Expose the workflow through an API endpoint.
Add integration tests and response validation.

One possible endpoint will be:

POST /api/ai/ask

Example request:

{
  "question": "Which products use sustainable packaging?"
}

The application will search its own indexed data and ask Mistral to generate an answer grounded in those results.

Final thoughts

This setup creates a practical local AI development environment while keeping data and model inference on the developer’s machine.

The most important lesson was to verify each connection independently:

Host to Ollama
Docker to Ollama
API to Qdrant
Browser to Open WebUI

Once those connections work, debugging the application layer becomes much easier.

The MyZubster AI integration is still evolving, but the infrastructure is now ready for the next phase: building and testing the RAG workflow.

What local model and vector database are you using for your AI projects?

Docker #ArtificialIntelligence #Python #Ollama #Mistral #Qdrant #RAG

Nicola’s MyZubster Pilot Now Runs Locally with Docker—and We Verified the Data Survives

Wed, 02 Sep 2026 09:00:51 +0000

Nicola’s MyZubster Pilot Now Runs Locally with Docker—and We Verified the Data Survives

Today, Nicola’s independent MyZubster MVP completed another verifiable development cycle.

The objective was not merely to build a Docker image.

We wanted to prove the complete local workflow:

Clone → Build → Start → Create → Persist → Restart → Recreate → Verify

We completed every step on Nicola’s Windows computer.

What the project already had

The MVP exposes a small observation API.

Its first verified user story was:

Create an observation → HTTP 201 → JSON persistence → API retrieval → automated test

That implementation was reviewed and merged through a public pull request:

PR #1 — Verify observation creation, persistence and retrieval

The next question was:

Can someone run the same capability locally without manually configuring the Python environment?

Making the environment reproducible

We added:

a Python slim Docker image;
a non-root application user;
Docker Compose configuration;
a persistent volume;
an API health check;
configurable host, port and data-file location;
Windows-oriented setup instructions;
Docker verification in GitHub Actions.

The work was reviewed in:

PR #2 — Add reproducible Docker setup for local development

GitHub Actions successfully:

built the image;
started the container;
called the API;
created an observation;
retrieved the saved observation.

After the CI passed, the pull request was merged.

The first problem was not in the code

Nicola cloned the repository:

git clone https://github.com/nicolaususnicola-lgtm/myzubster-mvp.git
cd myzubster-mvp

The first Compose command failed:

failed to connect to the docker API at
npipe:////./pipe/dockerDesktopLinuxEngine

Docker’s command-line tools were installed, but the Docker Desktop Linux engine was not running.

We checked and updated WSL:

wsl --version
wsl --status
wsl --update
wsl --shutdown

After Docker Desktop was started, docker info confirmed:

Linux containers;
WSL 2;
eight CPUs;
approximately 15.5 GB of RAM;
a functioning Docker server.

This distinction was important: reinstalling or changing the repository would not have fixed the problem.

Starting MyZubster

Nicola ran:

docker compose up --build -d
docker compose ps

The image was built and the API started successfully.

We then created an observation:

$body = @{
  description = "Prima osservazione Docker di Nicola"
  latitude = 44.0678
  longitude = 12.5695
} | ConvertTo-Json

Invoke-RestMethod `
  -Method Post `
  -Uri http://localhost:5000/api/observation `
  -ContentType "application/json" `
  -Body $body

The API returned an observation with ID:

b8e8d66b9bf5bd16

It included the description, coordinates and a UTC timestamp.

Verifying persistence

Reading the collection returned:

{
  "count": 1,
  "observations": [
    {
      "coordinates": {
        "lat": 44.0678,
        "lng": 12.5695
      },
      "description": "Prima osservazione Docker di Nicola",
      "id": "b8e8d66b9bf5bd16",
      "media_hash": "",
      "timestamp": "2026-09-02T08:51:57.067451+00:00"
    }
  ]
}

We then restarted the API service:

docker compose restart api

The same observation remained available.

But a container restart was not enough to prove the full persistence model.

Testing `down → up`

We removed the Compose environment:

docker compose down

The container stopped, while the named volume remained:

local     myzubster-mvp_observations-data

We deliberately avoided:

docker compose down -v

because -v would delete the data volume.

We then recreated the environment:

docker compose up -d

After the API returned, we queried it again.

The result still contained:

count: 1
id: b8e8d66b9bf5bd16

The observation survived both the container restart and the complete Compose recreation.

A problem we still found

During shutdown, the Flask development server did not terminate gracefully within Docker’s initial timeout.

The container eventually exited with code 137.

This did not delete the volume or corrupt the observation, but it exposed the next improvement:

replace Flask’s development server with Gunicorn;
verify graceful container shutdown;
repeat the persistence test;
add that behavior to CI.

The application is an MVP, not a production deployment, and the logs correctly say so.

What has actually been proven

We can now verify that:

the public repository can be cloned on Windows;
Docker builds the application;
Compose starts the API;
a health check confirms availability;
the API returns HTTP 201 for a valid observation;
the observation is persisted;
it can be retrieved through the API;
it survives a service restart;
it survives docker compose down followed by up;
no passwords or access tokens are required.

That is more valuable than saying “Docker support added.”

It is evidence that the workflow is reproducible.

Why this matters for MyZubster

MyZubster is exploring whether an ecosystem can scale through independently developed capabilities instead of only accumulating users.

Nicola’s MVP is still small.

But it now has:

public source code;
a verified API workflow;
automated tests;
Docker packaging;
persistent local storage;
successful CI;
evidence reproduced on the project owner’s computer.

This is the development model we are testing:

Build → Validate → Connect → Measure → Verify → Replicate → Expand

One human + one AI

The collaboration follows a human-controlled model:

Nicola owns and runs his project;
the AI assists with analysis, implementation and troubleshooting;
GitHub records the changes;
CI verifies the automated workflow;
local execution proves that the result works outside the development environment.

The AI does not decide that the software is finished.

The evidence tells us what works, while the remaining failures tell us what to improve next.

Next step

The next technical milestone is a graceful production-style container lifecycle:

add Gunicorn;
verify clean shutdown;
preserve the current persistent volume behavior;
repeat the local Windows test;
record the result publicly.

For now, Nicola can accurately say:

MyZubster runs locally with Docker and preserves its observation data.

Repository:
github.com/nicolaususnicola-lgtm/myzubster-mvp

Main ecosystem:
github.com/MyZubster-Ecosystem/myzubster

Website:
myzubster.com

What do you consider sufficient evidence that a Dockerized MVP is genuinely reproducible?

What Self Hosting An AI Agent Platform Actually Costs

Sun, 30 Aug 2026 02:03:11 +0000

A lot of the self hosting questions on here turn out to be hardware questions rather than software questions, and the answers usually skip the boring part. This is the version I wish someone had handed me before I rented the first box for an always on agent setup.

The Software Is Free, The Server Is Not

Most of the agent platforms worth running are a Docker install. Auto Learning Agents is one of them, so the license cost is zero and the entire recurring cost is the machine underneath. That sounds obvious until you price it, because the machine is the part that decides whether the thing is usable at all.

The reason you want a server in the first place is uptime. An agent that only runs while your laptop is open is a script. An agent that runs on a box with root access, comes back after a reboot, and keeps working while you sleep is a platform. That difference is entirely infrastructure.

What The Box Actually Needs

Root access is not optional, because the install assumes it. Past that, the requirement splits on one decision: are you calling a hosted model API, or running the model locally?

If you are calling an API, the platform itself is light. A cheap VPS handles a single user setup comfortably and CPU matters more than anything exotic.

If you are running the model locally, RAM becomes the binding constraint before anything else does. A quantized 7B model wants roughly 8GB just to sit resident, and it climbs quickly from there. The common mistake is sizing the box for the platform and forgetting that the model has to live in the same memory.

Where People Get Burned

Three things, roughly in the order they bite.

Disk fills up. Logs, model weights and container layers all grow, and nothing warns you until a write fails.

Memory gets oversubscribed. Two models resident at once on a box sized for one, and the OOM killer picks the process you cared about.

Nothing restarts. The host reboots for a kernel update and the agent quietly stays down for a day because the container was never set to come back on its own.

None of these are hard problems. They are just invisible until they happen to you.

Start Small And Upgrade When It Earns It

The honest advice is to start on the smallest box that fits the model you picked, run it for a week, and watch memory and disk before scaling anything. Most single user setups never outgrow that. Sizing up front for load you do not have yet is the most common way to make a free platform expensive.

One File, Six Services: Running AI Agents With Docker Compose

Thu, 27 Aug 2026 23:49:58 +0000

Most of us here already reach for Compose the moment a project grows past a single process, and agent work hits that point faster than almost anything else. What follows is the shape that keeps showing up once an agent stops being a script and starts being a system.

An Agent Is Never One Process

A working agent needs a runtime process, a model endpoint, a database for conversation history and agent state, and usually a vector store for retrieval. Add a queue once tasks run in the background, and something for traces once you need to know why a run went sideways. That is six services before anyone has written an interesting tool.

Running those by hand means remembering startup order, wiring hostnames and ports, and keeping six sets of environment variables in sync. Compose turns all of it into one declarative file with depends_on and health checks, so docker compose up produces the same stack on a laptop and on a server, and docker compose down leaves nothing behind.

The dependency isolation matters more here than in most stacks. Agent code pins specific versions of Python, PyTorch, and CUDA, and those pins conflict constantly. Two containers can run CUDA 12.4 and CUDA 11.8 side by side because each one carries its own dependency tree.

Three Patterns, Three Cost Profiles

The first pattern is API-backed. The agent container calls a hosted model, and the Compose file holds the runtime, a database, and whatever tools the agent needs. Minimal local resources, best available models, and a bill that scales linearly with usage.

The second runs a model server such as Ollama or vLLM in the same stack. The server holds the model in GPU memory and exposes an OpenAI compatible endpoint on the internal Docker network, so the agent reaches it by service name and configuration stays trivial. Per-call cost goes to zero and nothing leaves your infrastructure, but you own the GPU memory budget, and a large model can want anywhere from 20 to 80 GB of VRAM depending on parameter count and quantization.

The third is a hybrid that routes cheap high-volume calls to the local server and hard calls out to a frontier model. It is the pattern most teams land on eventually, and it is also the one that makes the routing logic worth testing.

The Parts That Bite Later

GPU access needs the device reservation in the Compose file and the container toolkit on the host, and it fails in a way that looks like a slow CPU run rather than an error. State needs named volumes, because a bind mount to a host path is the fastest way to lose a vector index during a rebuild. Service discovery is free inside the Compose network, which is exactly why it is worth being deliberate about which ports you publish to the host at all, since an unauthenticated model server on 0.0.0.0 is a real problem.

This guide to deploying AI agents with Docker Compose covers each of those in depth, along with the compose file anatomy and the move from a development stack to a production one.

Where Compose Stops Being The Answer

Compose is a single-host tool. When you need rolling updates across machines, autoscaling on queue depth, or real multi-tenancy, that is the Kubernetes conversation. Until then, a Compose file is the honest description of your architecture, and it is the artifact a new developer can read in two minutes and run in one command.

Why Your Simulation Does Not Reproduce On Another Machine

Thu, 27 Aug 2026 13:59:32 +0000

Most of us here ship code that has to behave the same on someone else's machine, and we lean on containers and lockfiles to get there. Scientific code has the same problem with a nastier failure mode, because when it breaks nothing crashes, the program just returns different numbers.

Three Errors, Not One

Numerical code carries three distinct kinds of error and each one needs a different response. Round-off error comes from finite precision, since IEEE 754 doubles hold about 15 significant decimal digits and subtracting nearly equal values throws most of them away. Truncation error comes from replacing a continuous operation with a discrete one, which is what a finite difference or a time step actually is. Modeling error is the gap between the equations and reality, and no amount of grid refinement touches it.

Refining the discretization fixes the second one, makes the first one slightly worse by adding operations, and does nothing at all for the third. Most arguments about a simulation being wrong turn out to be arguments about which of the three someone is looking at. This guide to scientific computing methods walks through each of them next to the numerical methods they come from.

Why The Same Code Gives Different Answers

Change the core count and the summation order changes. Switch GPU models and the reduction tree changes. Let the compiler vectorize differently and the rounding changes. Different math libraries return different last digits for the same transcendental function. Every one of those is a legal, standards conforming result, and in a chaotic system the difference grows exponentially instead of staying in the noise.

That is why bitwise reproduction is the wrong target for a lot of scientific code. The reproducible quantity is the ensemble average with error bars, not the individual trajectory.

Verification Is Not Validation

Verification asks whether you solved the equations correctly, which is a software question. Is the method implemented without bugs, and does it converge at the order it claims? Validation asks whether you solved the right equations, which is a physics question you answer against experiment.

The method of manufactured solutions is the technique worth stealing here. You choose a solution first, substitute it into the governing equations to generate whatever source terms make it exact, then check that the code converges to it at the expected rate. That turns looks about right into a pass or fail test, which is exactly what unit tests do for ordinary code.

What Actually Fixes It

The habits are ones we already have, applied to the whole environment rather than just the source. Git pins the code version behind each figure. Docker or Singularity pin the libraries and the OS layer. Snakemake or Nextflow record parameters and step order so a run can be replayed instead of remembered. Regression tests catch the day a refactor moves a result by 1e-9, which is the change nobody notices until a reviewer asks about it.

None of that is exotic. It is the same reproducibility discipline we expect from a build, pointed at a program whose output is a number instead of a binary.

Why safe vs. fast is a false choice for platform teams

Fri, 21 Aug 2026 21:24:10 +0000

Modern cloud architecture is facing a massive identity crisis. We are asking infrastructure to run workloads that software engineers a decade ago would have deemed hopelessly ill-advised. Third-party user plugins executing arbitrary code, autonomous AI agents calling APIs and compiling dynamic scripts on the fly, and densely packed multi-tenant clusters where direct competitors share the exact same physical silicon. To cope, the industry defaulted to the same old, traditional security primitives like Kubernetes namespaces, seccomp profiles, AppArmor rules, and in some cases, complex system call allowlists. But all these tools rely on the same outdated assumption that we can easily predict what a workload is going to do before it does it.

Namespaces are an organisational abstraction, not a security boundary. Every standard Docker container share a single Linux kernel. This is the ultimate single point of failure and the broadest attack surface in modern computing. A single container escape or kernel panic doesn't just crash a pod, it also has the blast radius to compromise every tenant on that same node. To avoid this, teams usually default to heavy, expensive alternatives like cluster-per-tenant sprawl, dated VM overhead that destroys margins, or strict syscall allowlists that break non-deterministic AI agents. Thankfully, Edera was built to eliminate this tradeoff.

Operating as a Type-1 hypervisor, Edera gives every workload its own isolated Linux kernel in a lightweight execution boundary called a Zone. It delivers VM-grade architectural isolation at bare-metal speed (<1% CPU overhead, 766ms startup time) with zero hardware virtualisation dependencies (VT-x) required. The focus of this blog post was to discuss how Edera redefines the core value drivers of modern infrastructure for the workloads that many operations teams simply call "too risky."

Multi-tenancy for Kubernetes

Kubernetes namespaces give you a false sense of security. They organise your workloads, but at the system level, every container on a node communicates directly with the host Linux kernel. When a vulnerability like a kernel privilege escalation hits, namespace boundaries evaporate. A container escape provides a direct line to every other tenant sharing that node. To avoid this shared-kernel threat, enterprise engineering teams traditionally resort to cluster-per-tenant architectures. While this solves the security problem, it introduces massive operational friction:

Endless patching cycles
Doubling or tripling cloud control planes
Splintered monitoring and/or logging stacks
Escalating cloud infrastructure bills that decimate gross margins

Edera eliminates the shared host kernel entirely. By deploying as a hardened runtime in just two lines of YAML, Edera wraps every Kubernetes pod in its own isolated Zone powered by a dedicated Linux kernel.
If a workload panics, only its specific Zone crashes. If a malicious process attempts a container escape, it hits a Type-1 hypervisor boundary with no host on the other side. Network traffic is similarly hardened: every workload receives a cryptographic identity via SPIFFE/SPIRE, paired with private networking that ensures packets never touch the host interface. The result is a 60% reduction in node sprawl and total immunity against shared-kernel CVEs. This design achieves true multi-tenant density on shared hardware without taking on shared risk.

Multi-tenancy for GPUs

GPUs are the most expensive, underutilised asset in the modern datacentre. The vast majority of enterprise GPU clusters operate at a dismal 20% to 30% resource utilisation. Inference workloads idle while waiting for requests, model development tasks consume full cards for basic interactive research, and multi-tenant sharing is routinely blocked by security and compliance teams. Why? Because traditional GPU sharing mechanisms (like MIG or process-level slicing) lack hard isolation boundaries. If two competing teams or customers share a single physical GPU, a driver-level exploit or memory leak in one application can crash the entire card or read sensitive model weights from adjacent memory.

Edera extends hypervisor-level isolation directly down to physical accelerator hardware, allowing organisations to securely partition GPUs into right-sized virtual GPUs (vGPUs) across multiple tenants. Edera allows teams to safely drive GPU utilisation from 20–30% up to 60–80% by co-locating dense inference models and fractional development environments on the same card.

In traditional systems, all containers must share the host’s exact GPU driver and kernel version. Edera allows different kernel versions to run per Zone. You can run legacy ML frameworks requiring older drivers alongside cutting-edge setups on the same physical server. Likewise, memory and compute partitions are isolated at the hypervisor boundary. If an ML job triggers a CUDA out-of-memory error or driver panic, it is contained inside its Zone without impacting neighbouring workloads on the GPU.

AI agent execution

AI agents are fundamentally changing software architecture. Unlike legacy microservices that execute predictable, pre-compiled code paths, autonomous agents are non-deterministic by nature. They write and run dynamic scripts, execute terminal commands, browse the web, parse unpredictable web inputs, and chain complex tools together in real time. This introduces a massive security dilemma. Traditional container security relies on predicting behaviour:

system call allowlists block unexpected behaviours.
seccomp profiles dictate the allowable system calls.
AppArmor / SELinux restrict filesystem access based on known paths.

Attempting to enforce rigid system call allow-lists on an autonomous agent running tools like Claude Code, LangChain, CrewAI, or AutoGen will inevitably break the agent. But running agents with unrestricted host kernel access invites severe prompt injection, arbitrary code execution, and lateral network movement. Edera shifts this paradigm from restricting agents to rightfully containing them.

Instead of trying to predict every system call an agent might make, Edera grants the agent an isolated Zone with a complete, fully functional Linux kernel supporting 350+ standard system calls. The agent gets complete operational autonomy to compile code, invoke binaries, and manage processes. However, because the Zone is structurally isolated by Edera’s hypervisor, the blast radius of a compromised or rogue agent is mathematically bounded to exactly one workload.

With a rapid 766ms Zone startup time, developers can dynamically spin up an isolated environment for a single agent execution step and tear it down immediately after. This ends up delivering near-native speed without risking your host infrastructure.

Untrusted code execution

Whether processing customer-submitted Python scripts, executing webhooks, running third-party plugins, or compiling LLM-generated code snippets, running untrusted code is a core requirement for modern SaaS platforms. Historically, engineering teams faced three bad choices for untrusted code execution:

The shared kernel in Docker and Kubernetes offered fast performance, but extreme security risk since a single kernel vulnerability can lead to an entire host takeover.
The system call interception approach seen in gVisor worked. It's safe, but incurs heavy performance penalties (up to 59% build overhead) and frequent application breakages due to missing syscalls.
The traditional MicroVM isolation method, as seen with Kata containers, provides a secure VM boundary, which is a significant improvement, but requires nested hardware virtualisation (VT-x), incurring high cold-start times (~2.5x slower) and blocking deployment on 93% of public cloud instances.

In this context, Edera eliminates the trade-off between performance, security, and cloud portability:

1) Near-native speeds:
Operates with less than 1% CPU overhead and somewhere around 5% build overhead.
Delivers up to 12x faster performance than gVisor under heavy network and I/O stress.

2) Support for over 350 syscalls:
Complete syscall compatibility means zero application debugging or allowlist maintenance.
The code runs exactly as you would expect it to run on bare metal.

3) Extensive cloud compatibility:
Because Edera does not require hardware VT-x extensions, it offers 93% cloud instance coverage.
Runs natively on standard public cloud VMs, bare-metal nodes, and edge devices alike.

Trust, compliance, and confidential computing (Cryptographic proof of isolation)

In highly regulated sectors such as fintech, healthcare, and the defence sector, security controls must be provable to auditors, auditors' tools, and prospective customers. Claiming that "our software is isolated by policy" no longer passes vendor risk assessments. Furthermore, traditional cloud security models protect data at rest and in transit, but leave data exposed in use inside host memory. While hardware-based Trusted Execution Environments (TEEs) and Confidential Computing solve parts of this puzzle, they often demand specialised hardware, proprietary SDKs, and significant application refactoring.

Every Edera Zone is assigned an immutable, cryptographic identity via SPIFFE/SPIRE. Security teams can generate verifiable cryptographic audit trails proving that workloads executed inside isolated, untrusted boundaries. TEEs (like AMD SEV or Intel SGX) protect workloads from a compromised host hypervisor. Edera protects the infrastructure and neighbouring tenants from a compromised workload. Together, Edera and TEEs provide complete, end-to-end confidential computing without requiring specialised hardware for every standard pod. Furthermore, Edera’s core architectural isolation primitives achieved zero critical findings during a comprehensive 4-week public security audit conducted by Trail of Bits.

Observability & tuning

A major downside of traditional virtualisation and sandboxing technologies is the "black box" effect. When you wrap a container inside a heavy VM, you frequently lose deep observability. Standard host-level agents (like eBPF probes, Prometheus exporters, or APMs) struggle to see inside the guest environment, forcing teams to inject monitoring sidecars into every single tenant container. This again increases the memory overhead and telemetry complexity.

Edera delivers enhanced runtime observability that gives platform operators deep, real-time visibility into workload behaviour without sacrificing security boundaries. See exactly what system resources, memory channels, and I/O operations every workload is consuming in real time from the hypervisor layer. Instead of drowning in thousands of noisy runtime alert logs ("Alert: suspicious /etc read attempt" from Falco), Edera’s structural isolation prevents lateral movement and privilege escalation at the boundary layer. Finally, track true CPU/RAM consumption per Zone to right-size multi-tenant pods, optimise GPU memory allocation, and eliminate waste across cloud fleets with total confidence.

My closing statement is this - the next decade of cloud computing will definitely belong to platform teams that are able to run complex, untrusted, and non-deterministic workloads safely at scale. Choosing between developer velocity, cloud spend margins, and foundational security is a false choice born from the legacy way of thinking when everyone relied on a shared-kernel architecture. By replacing the shared host kernels with cryptographically verified, hypervisor-isolated Zones, Edera lets you move fast, cut cloud spend, and run the next-gen AI workloads without the fear of unexpected behaviour.

How to Give AI Agents a Safe Sandbox Using Docker

Mon, 10 Aug 2026 15:21:23 +0000

AI agents that can execute code, browse files, or run shell commands are powerful - and risky. Docker sandboxes let you hand an agent real execution capability without letting it touch anything it shouldn't.

Disposable Containers as Agent Workspaces

When an AI agent needs to run code or interact with a filesystem, the naive approach is to let it run directly on the host. That works until it doesn't - a runaway loop, an unintended file deletion, or a dependency conflict can wreck your environment.

The better pattern is to spin up a fresh Docker container per agent task, give it only what it needs, and throw it away when the task is done. Each container provides an isolated workspace: it has its own filesystem, its own process namespace, and no access to host resources unless you explicitly grant them. The agent runs inside it, does its work, and the container is removed. If something goes wrong, the blast radius is one disposable container, not your machine or your production environment.

This pattern is especially useful for agents that use tool-calling (where the LLM triggers actual function execution) or code interpreter steps - any workflow where the model's output becomes a live command.

Real Example: Spin Up and Tear Down an Agent Sandbox

Here's a minimal pattern using the Docker SDK for Python to create a sandboxed execution environment for an agent task:

import docker

client = docker.from_env()

def run_in_sandbox(code: str) -> str:
 container = client.containers.run(
 image="python:3.12-slim",
 command=["python", "-c", code],
 mem_limit="128m",
 network_disabled=True,
 remove=True, # auto-delete after exit
 stdout=True,
 stderr=True,
 )
 return container.decode("utf-8")

output = run_in_sandbox("print(sum(range(100)))")
print(output) # 4950

A few details worth noting: network_disabled=True cuts off outbound calls from inside the container - critical if the agent-generated code might try to exfiltrate data or call external APIs unexpectedly. mem_limit prevents a runaway process from consuming host memory. remove=True means the container is deleted the moment it exits, so you're not accumulating stale containers.

For more complex agent setups (multi-step tasks, file I/O between steps), you can mount a temporary volume for the duration of the task and unmount it afterward, keeping the isolation intact while still allowing artifact passing between agent turns.

Key Takeaways

Giving AI agents a throwaway Docker container per task limits damage from unexpected or malicious code execution.
Disabling networking and capping memory are the two most important constraints to set from the start - not as an afterthought.
This pattern works with most agent frameworks (LangChain, LlamaIndex, custom tool-calling loops) since it wraps execution at the infrastructure layer, not inside the framework itself.

Are you currently running agent-generated code directly on the host, or do you already have an isolation layer in place - and if so, what does it look like?

Sources referenced: HackerNews - Docker Sandboxes discussion (403 points, 258 comments)

Docker Desktop Is the New Adobe CC: Bloated & Expensive

Sun, 02 Aug 2026 14:09:21 +0000

Let's start with an uncomfortable question. When's the last time you actually looked at what's running when you open Docker Desktop, versus what you think is running? Because I did, and it ruined my week a little, so now it's going to ruin yours too.

From "lightweight alternative to VMs" to the thing it was built to replace

Here's the pitch Docker sold everyone around 2013: forget heavy virtual machines, forget booting a whole guest OS just to run one process, containers share the host kernel and give you VM-like isolation for a fraction of the overhead. Genuinely great idea. Genuinely changed how the entire industry ships software. Nobody's arguing with the concept.

The problem is what happened to the implementation on the two operating systems most developers actually use day to day. On macOS and Windows, Docker Desktop runs every single container inside a hidden Linux virtual machine — LinuxKit on the backend, spun up the moment you launch the app. Yes, really: the tool whose entire founding pitch was "you don't need a VM anymore" ships you one anyway, just quietly, behind a whale icon, so you don't have to think about it. It's giving "we don't sell your data, we just process it" energy, and if that sentence means something to you, you already know exactly the kind of institutional gaslighting I'm talking about.

That VM idles at somewhere around 1-4GB of RAM doing absolutely nothing — no containers running, no builds happening, just existing, breathing, judging you from the menu bar. On Windows the overhead is worse: Microsoft's own docs flag roughly an extra 4GB of memory requirement specifically because you're running a VM on top of a host that isn't natively Linux. Compare that to a native Linux box, where the "VM" is just... the kernel you already have. Docker on Linux doesn't need this charade. Docker on your MacBook does, and it's been quietly costing you a chunk of your RAM budget since the day you installed it.

The GUI is a browser pretending to be a dashboard

Here's the part that should genuinely make you angry once you know it: Docker Desktop's dashboard — the pretty window that shows you a list of running containers and their logs — is an Electron app. Which means, under the hood, it's Chromium. A full web browser. Docker's own public roadmap confirms it outright, and their own release notes have shipped fixes for the dashboard throwing ERR_FAILED errors because process-hardening policies conflicted with Chromium — an error message that should not exist in a tool whose entire job is "show text in a box." Security researchers have literally opened the Chrome DevTools console inside Docker Desktop using a Konami-code-style key combo, because it's Chromium under a trench coat, and Chromium ships DevTools.

Sit with that for a second. The tool that replaced heavyweight virtual machines with "lightweight" containers is now shipping you a second heavyweight virtual machine, wrapped in a second heavyweight browser engine, so you can look at logs you could've read with docker logs -f and a text editor that's been installed on your machine since 2004.

The years-long soap opera of just... reading a file

If the VM and the browser-in-a-box weren't enough, let's talk about what happens when you mount your actual project folder into a container — something approximately every developer using Docker on a Mac does on day one. For years, the default file-sharing backend was osxfs, and osxfs was, to use the precise technical term, garbage. Developers running Symfony, Laravel, or anything with a bloated node_modules folder would watch page loads take multiple seconds because every file read had to cross the host-to-VM boundary through a genuinely slow translation layer. Docker's answer was gRPC-FUSE, which was faster, in the same sense that being hit by a slightly smaller truck is an improvement. It took until 2022 for VirtioFS to finally ship as a real fix, and Docker's own benchmarks claimed up to 98% faster file sync versus the old backend.

Here's the punchline: even with VirtioFS, independent benchmarks still show it running 2-5x slower than native Linux for workloads with lots of small files — which describes precisely the node_modules situation that made Mac developers' hair go gray in the first place. You went from "unusably slow" to "noticeably slow," and Docker shipped a blog post celebrating it like they'd solved the problem instead of just making the tax smaller.

And then they figured out how to charge you for the privilege

In 2021, Docker changed the terms: Docker Desktop went from "free forever, no asterisks" to "free unless your company crosses 250 employees or USD 10 million in revenue, in which case pay up." Fair enough, companies need revenue, I'm not going to pretend GPL-licensed goodwill pays anyone's rent. But by 2026 the tiers have fully calcified into the SaaS pricing ladder you'd expect from a project management tool, not a container runtime: Personal is free, Pro runs about USD 9 per user per month, Team lands around USD 15 per user per month, and Business tops out near USD 24 per user per month for the privilege of SSO, audit logs, and something called "Hardened Docker Desktop" — which is a genuinely funny name for a security feature, implying the regular one is, what, soft? Squishy? Vulnerable to a stiff breeze?

Annual billing barely helps on the top tier either — Business gets effectively zero discount for committing a year in advance, which is the kind of pricing decision that only makes sense if you've already accepted that switching costs are your actual product. And here's the twist that should bother you more than the price tag: Docker's own list pricing has been creeping up 3-7% a year through 2025-2026, the exact playbook every SaaS company runs once they know you're locked in. You didn't sign up for a subscription. You signed up for a Docker Desktop-shaped mortgage.

And it doesn't even wait to be asked. By default, Docker Desktop adds itself to your login items, so you open your laptop to check one email or watch one YouTube video, and somewhere behind your open tabs a multi-gigabyte VM has already quietly spun itself up and started warming your lap through the chassis for containers you have no intention of running today.

Meanwhile, the actual alternatives got quietly good

This is normally the part of the post where I'd tell you to just suffer through it because "there's no real alternative." That stopped being true a while ago, and pretending otherwise at this point is just Stockholm syndrome with extra steps.

Podman is the one worth taking seriously first, because it doesn't ask you to change how you think, just what daemon you trust. No background daemon running as root by default — Podman runs containers as your own user, rootless, which means a container escape doesn't hand an attacker root on your actual machine, it hands them your own limited user account, which is a considerably less exciting Tuesday for everyone involved. It speaks the same OCI image format, the CLI is close enough to Docker's that muscle memory mostly survives the switch (alias docker=podman and half your team won't even notice), and it doesn't need a hidden VM babysitting a whale icon just to exist. If your objection to switching is "but my docker-compose.yml files," Podman Compose exists specifically to make that objection irrelevant.

Nix and NixOS are the other end of the spectrum, and I'm not going to pretend this one is for everyone — it's for the specific flavor of masochist who reads a man page for fun and considers make "too much magic." Nix's whole premise is that you don't containerize your environment, you declare it: a Nix expression describes exactly which packages, which versions, which dependencies your project needs, and Nix builds that environment reproducibly, byte-for-byte, on any machine running the Nix package manager — no container boundary required, because the isolation comes from content-addressed, immutable package derivations instead of kernel namespaces. It's genuinely the most correct solution to "works on my machine" that currently exists. It is also, in fairness, the solution most likely to have you debugging a syntax error in a language that looks like someone smashed Haskell and JSON together at 2am. Hardcore. Occasionally the right answer anyway.

And if the previous two paragraphs made your palms sweat because you actually like having a window with buttons in it — fair, not everyone wants to live in a terminal. Colima is the unofficial Mac-community hero here: it spins up a genuinely minimal VM using macOS's own native virtualization framework and hands you a clean Docker-compatible CLI, no Electron, no subscription tiers, no telemetry dashboard, at a fraction of Docker Desktop's footprint. Rancher Desktop covers similar ground with an actual GUI attached, for people who want Podman or dockerd under the hood but still want to click a button instead of memorizing flags. Neither one asks about your headcount. Neither one ships you a browser to read log lines.

So what do you actually do with this

Nobody's saying rip Docker out of your CI pipeline this afternoon — for a lot of teams, the GUI, Docker Scout's vulnerability scanning, and Build Cloud's CI acceleration genuinely earn their subscription, and that's a legitimate trade to make with eyes open. But if you're a solo developer or a small team paying the Personal-tier RAM tax just to run docker build and docker run locally, you are paying VM overhead and possibly a subscription fee for functionality Podman gives you for free, without the hidden VM, without the daemon running as root, and without ever once asking about your headcount.

Try Podman for a week on your actual local workflow. If your muscle memory survives the alias, you've just gotten your RAM back for nothing. If it doesn't — fine, go back to the whale, no judgment, some relationships are just complicated. But at least now you know exactly what you're paying for, and exactly what's quietly running behind it every time you open the app.

Skopeo, Crane, and regctl: Container Image Management Without the Docker Daemon (2026)

Tue, 28 Jul 2026 10:00:00 +0000

The Problem: Docker Is Overkill for Image Operations

You need to copy an image from Docker Hub to your private registry. Or inspect a manifest before pulling. Or delete old tags programmatically. Or sync an entire repository during a migration.

Related reading: Kaniko, BuildKit and Image Volumes.

The instinct is to reach for Docker. But Docker requires a running daemon, root access (or group membership that amounts to the same thing), and pulls the entire image to disk just to read its metadata. For CI pipelines, GitOps workflows, and platform tooling, that’s a significant overhead for what should be lightweight registry operations.

This is the problem that daemonless container image tools solve. Skopeo pioneered the category; today it has real competition from crane, regctl, and ORAS — each with different strengths and ideal use cases.

This article gives you the practical comparison to pick the right tool for your workflow.

The Contenders

Tool	Maintainer	Language	Daemon required
Skopeo	Red Hat / containers	Go	No
crane	Google / ko-build	Go	No
regctl	regclient	Go	No
ORAS	CNCF	Go	No
cosign	Sigstore / OpenSSF	Go	No

All five are Go binaries, statically compiled, and work directly against the OCI Distribution Spec. None of them require Docker or any container runtime.

Skopeo

Skopeo was the first major tool to address daemonless image operations, released by Red Hat in 2016 as part of the containers/image ecosystem (alongside Podman and Buildah).

What Skopeo does well

Image inspection without pulling:

skopeo inspect docker://registry.k8s.io/pause:3.9

Returns full image metadata — digest, layers, labels, architecture, OS — without downloading a single layer. Useful in admission controllers, policy checks, and pre-deployment validation.

Cross-registry copying:

skopeo copy 
  docker://docker.io/library/nginx:1.27 
  docker://harbor.internal/library/nginx:1.27

Copies image manifests and layers directly between registries, bypassing your local machine entirely. The image never touches your disk.

Multi-arch handling:

skopeo copy --all 
  docker://docker.io/library/nginx:1.27 
  docker://harbor.internal/library/nginx:1.27

The --all flag copies the full manifest list, preserving all architectures (linux/amd64, linux/arm64, etc.). This is critical when mirroring images for multi-arch clusters.

Registry synchronization:

skopeo sync 
  --src docker 
  --dest docker 
  --all 
  docker.io/library/nginx 
  harbor.internal/mirrors/

skopeo sync mirrors an entire repository, including all tags. You can also use a YAML file to define which images and tags to sync — useful for air-gapped environment bootstrapping.

Tag deletion:

skopeo delete docker://harbor.internal/myapp:old-tag

Useful in CI for cleanup pipelines. Note that registry-side deletion requires the registry to have the DELETE method enabled.

Skopeo’s weaknesses

No image modification: Skopeo copies and inspects, but doesn’t build or modify images
Tag listing is verbose: skopeo list-tags returns JSON you need to parse
No retry logic by default: transient network errors in long sync operations require wrapping with retry scripts
Auth configuration: relies on containers/auth.json format, which differs from Docker’s ~/.docker/config.json (though it supports both)

When to use Skopeo

Air-gapped environment image mirroring
CI pipelines that need to copy or inspect images without Docker
Platform teams on Red Hat / OpenShift stacks
Any workflow already using Podman or Buildah

Crane

Crane is Google’s answer to Skopeo, developed as part of the ko project and later extracted into its own tool. It’s simpler, more scriptable, and has a cleaner CLI design.

What Crane does well

Tag listing:

crane ls registry.k8s.io/pause

No JSON parsing needed. One tag per line. Pipe directly into grep, sort, head.

Digest resolution:

crane digest docker.io/library/nginx:1.27

Returns the image digest. Combine with yq or sed to pin image references in Helm values or Kubernetes manifests.

Image copying:

crane cp docker.io/library/nginx:1.27 harbor.internal/library/nginx:1.27

Same capability as Skopeo’s copy, arguably with a cleaner syntax.

Manifest inspection:

crane manifest docker.io/library/nginx:1.27 | jq .

Returns raw manifest JSON. Useful when you need the exact manifest for digest verification or policy enforcement.

Tagging and retagging:

crane tag harbor.internal/myapp:abc123 harbor.internal/myapp:stable

Adds a new tag to an existing image without re-uploading layers. The tag operation is purely a manifest pointer update.

Flattening images:

crane flatten docker.io/library/ubuntu:24.04 -t harbor.internal/ubuntu:flat

Squashes all layers into one. Reduces layer count for images where layer history doesn’t matter.

Crane’s weaknesses

No sync command: unlike Skopeo, crane has no built-in repository sync. You script it yourself with crane ls + crane cp in a loop
Less mature multi-arch support: crane cp supports multi-arch but the UX is less explicit than Skopeo’s --all
No delete command: doesn’t implement registry deletion

When to use Crane

CI/CD scripting where you want clean, pipeable output
Digest pinning workflows
Lightweight image tagging operations
When you’re already in the ko / Google Cloud ecosystem

regctl

Regctl is the least known of the three but arguably the most feature-complete. It’s the CLI for the regclient Go library and covers use cases that Skopeo and crane leave out.

What regctl does uniquely well

Image modification without rebuild:

regctl image mod myimage:tag 
  --label "org.opencontainers.image.version=1.2.3" 
  --replace

You can add/change labels, annotations, and config fields directly on an existing image in the registry — without pulling, rebuilding, or pushing a new image. This is impossible with Skopeo or crane.

Layer operations:

# Remove a specific layer from an image
regctl image mod myimage:tag 
  --layer-rm sha256:abc123... 
  --replace

Useful for removing accidentally included secrets or large unnecessary layers from published images.

OCI artifact support:

regctl artifact put 
  --media-type application/vnd.example.config.v1+json 
  --config config.json 
  file.tar.gz 
  harbor.internal/myartifacts:v1

Regctl has solid OCI artifact support alongside standard image operations.

Formatting and output:

regctl tag list harbor.internal/myapp --format '{{range .}}{{println .}}{{end}}'

Go template formatting throughout. Useful for integrating into shell scripts without jq.

Referrers (OCI 1.1):

regctl manifest get-list harbor.internal/myapp:v1 --referrers

Lists referrers (signatures, SBOMs, attestations) attached to an image via the OCI 1.1 referrers API.

Regctl’s weaknesses

Smaller community: fewer examples, less StackOverflow coverage
Steeper learning curve: more commands, more flags
Less packaging: not in most distro repos by default

When to use regctl

Image post-processing (labels, annotations, layer removal) without rebuild
Advanced manifest and referrer workflows
When you need OCI artifact operations alongside image operations

ORAS

ORAS (OCI Registry As Storage) is a CNCF project focused specifically on OCI artifact management — pushing and pulling arbitrary files to container registries, not necessarily container images.

# Push a Helm chart as an OCI artifact
oras push harbor.internal/charts/myapp:1.0.0 
  --artifact-type application/vnd.helm.chart.v1+tar 
  mychart.tgz

# Push SBOM
oras push harbor.internal/myapp:v1 
  --artifact-type application/spdx+json 
  sbom.spdx.json

# Pull
oras pull harbor.internal/charts/myapp:1.0.0

ORAS is not a direct Skopeo replacement — it’s for when your registry is a general-purpose artifact store, not just a container registry. Helm OCI, SBOMs, attestations, and policy bundles all benefit from ORAS.

cosign

Cosign from Sigstore is not a general-purpose image tool — it’s specifically for supply chain security. But it’s increasingly part of any container image workflow.

# Sign an image
cosign sign --key cosign.key harbor.internal/myapp:v1@sha256:abc123...

# Verify
cosign verify --key cosign.pub harbor.internal/myapp:v1

# Attach SBOM
cosign attach sbom --sbom sbom.spdx harbor.internal/myapp:v1

# Keyless signing (Sigstore)
cosign sign harbor.internal/myapp:v1

Cosign integrates with OIDC providers for keyless signing (no key management required), which is the direction the ecosystem is moving. If you’re building a supply chain security practice, cosign is mandatory, not optional.

Side-by-side comparison

Operation	Skopeo	Crane	regctl
Inspect image	`inspect`	`manifest`	`manifest get`
Copy image	`copy`	`cp`	`image copy`
Copy all arches	`copy --all`	`cp` (auto)	`image copy`
Sync repository	`sync`	script it	script it
List tags	`list-tags` (JSON)	`ls` (plain)	`tag list`
Delete tag/image	`delete`	—	`tag delete`
Modify labels	—	—	`image mod`
Remove layer	—	—	`image mod`
OCI artifacts	limited	limited	`artifact`
Referrers (1.1)	—	—	`manifest get-list`

Practical workflows

Mirror images for air-gapped clusters (Skopeo)

# sync-list.yaml
docker.io:
  images:
    library/nginx:
      - "1.25"
      - "1.26"
      - "1.27"
    library/redis:
      - "7.2"
      - "7.4"

skopeo sync 
  --src yaml 
  --dest docker 
  --all 
  sync-list.yaml 
  harbor.internal/mirrors/

Pin image digests in CI (Crane)

#!/bin/bash
# Update image digests in values.yaml
for image in nginx:1.27 redis:7.4; do
  digest=$(crane digest docker.io/library/${image})
  echo "docker.io/library/${image}@${digest}"
done

Combine with yq to update Helm values files automatically, ensuring reproducible deployments.

Retag without re-pushing (Crane or regctl)

# After a successful deploy to staging, promote to production
crane tag harbor.internal/myapp:${GIT_SHA} harbor.internal/myapp:production

No layer transfer. The operation is a metadata update in the registry.

Add OCI annotations post-build (regctl)

regctl image mod harbor.internal/myapp:v1.2.3 
  --annotation "org.opencontainers.image.source=https://github.com/org/repo" 
  --annotation "org.opencontainers.image.revision=${GIT_SHA}" 
  --replace

Attaches build metadata to an image already in the registry, without a rebuild.

Supply chain security pipeline

# 1. Build and push
docker buildx build --push -t harbor.internal/myapp:${GIT_SHA} .

# 2. Generate SBOM
syft harbor.internal/myapp:${GIT_SHA} -o spdx-json > sbom.spdx.json

# 3. Attach SBOM
cosign attach sbom --sbom sbom.spdx.json harbor.internal/myapp:${GIT_SHA}

# 4. Sign (keyless with OIDC in CI)
cosign sign harbor.internal/myapp:${GIT_SHA}

# 5. Verify in admission controller or deployment pipeline
cosign verify 
  --certificate-identity-regexp="https://github.com/org/repo" 
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" 
  harbor.internal/myapp:${GIT_SHA}

Installation

All tools install as single static binaries:

# Skopeo (via package manager)
brew install skopeo                    # macOS
dnf install skopeo                     # RHEL/Fedora
apt install skopeo                     # Debian/Ubuntu

# Crane
brew install crane
# or binary release
curl -sL https://github.com/google/go-containerregistry/releases/latest/download/go-containerregistry_Linux_x86_64.tar.gz | tar xz crane

# regctl
curl -sL https://github.com/regclient/regclient/releases/latest/download/regctl.linux.amd64 -o /usr/local/bin/regctl
chmod +x /usr/local/bin/regctl

# ORAS
brew install oras

# cosign
brew install cosign

Which tool should you use?

Use Skopeo if: you’re on a Red Hat / OpenShift stack, you need repository sync, or you’re building air-gapped environment pipelines. It’s the most battle-tested and widely packaged.

Use Crane if: you’re scripting image operations in CI and want clean, composable CLI output. crane ls + crane cp + crane digest cover 80% of automation use cases with minimal friction.

Use regctl if: you need to modify images post-build, work with OCI referrers, or want the most complete feature set for a registry client. It has a higher learning curve but can replace both Skopeo and crane for advanced workflows.

Use ORAS if: you’re using a registry to store non-image artifacts — Helm charts, SBOMs, policy bundles, ML models.

Use cosign regardless of which of the above you pick, as soon as supply chain security matters to your organization. It’s not a replacement for the others — it’s a complement.

In practice, most platform teams end up using 2-3 of these tools together. Crane for day-to-day scripting, Skopeo for sync jobs, cosign for signing, ORAS for artifact storage.

FAQ

Can I use these tools with private registries?

Yes. All support standard registry authentication. Crane and Skopeo both read from ~/.docker/config.json. Regctl has its own config file (~/.regctl/config.json) but can import Docker credentials. Set DOCKER_CONFIG to point to your credentials file in CI environments.

Do these work with Docker Hub rate limits?

Yes, and they’re often more efficient than the Docker CLI because they only fetch manifest metadata for inspect operations, not full layers. For heavy pull workloads, authenticate with your Docker Hub credentials to get higher rate limits.

What about ECR, GCR, and Azure Container Registry?

All tools support these with the appropriate credential helpers. For ECR, use docker-credential-ecr-login. Crane has native ECR support via the --platform flag and crane auth commands. Skopeo supports ECR via --creds "AWS:$(aws ecr get-login-password)".

Are these tools safe to run in Kubernetes pods?

Yes. Since they require no daemon and no elevated privileges for read operations, they’re well-suited to r

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.

Coolify: The Complete Manual Setup Guide (For When the Auto-Install Script Won't Cut It)

Thu, 23 Jul 2026 05:15:31 +0000

Coolify's one-line install script is great — until it isn't. Right now it officially supports Ubuntu 20.04, 22.04, and 24.04 LTS. If you're running anything newer (Ubuntu's already on 26.04 LTS), the script won't work and you're left doing it manually.

This is that manual walkthrough — set up in the order that fits a security-first VPS workflow rather than the order Coolify's own docs use. If you've been following along with the Ansible playbooks from earlier in this series, this picks up right where that left off.

Minimum Hardware Requirements

CPU: 2 cores
Memory: 2 GB RAM
Storage: 30 GB free

Coolify can technically run below this, but it's not recommended.

Prerequisites

Before touching Coolify itself, you'll need:

SSH access to your VPS
CURL installed
Docker Engine installed

If you're reconnecting to a server you've rebuilt or re-provisioned, clear the old fingerprint first:

ssh-keygen -f '/home/your-path/.ssh/known_hosts' -R 'your-vps-ip'

Installing SSH

If you followed the earlier videos in this series, OpenSSH is already installed. If not:

sudo apt update && sudo apt install -y openssh-server

Confirm it's running and check which port it's listening on (you should have already changed this from the default 22 — see the VPS security video):

sudo systemctl status ssh
sudo ss -tulpn | grep ssh

Installing CURL

sudo apt update && sudo apt install -y curl
curl --version

curl and ca-certificates also get installed as part of the apt-update Ansible playbook below, so this may already be handled.

Running the First Ansible Playbook

Connect Ansible to the VPS:

ANSIBLE_HOST_KEY_CHECKING=FALSE ansible -i ./inventory/hosts vpsDemo -m ping --user root --ask-pass

Then run the update playbook:

ansible-playbook ./playbooks/apt-update.yml --user root -e "ansible_port=22" --ask-pass --ask-become-pass -i ./inventory/hosts

If you haven't set up the Ansible inventory and playbooks from the earlier videos, do that first — this guide assumes they're already in place.

Installing Docker Engine

Remove any conflicting packages first:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc | cut -f1)

Add Docker's official GPG key and repo:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Verify it worked:

sudo systemctl status docker
sudo docker run hello-world

Creating a Non-Root Admin User

Coolify's own docs assume you're using the root account. Since root login is disabled as part of the security hardening earlier in this series, we create a dedicated user with passwordless sudo instead.

Run the second playbook to create that user:

ansible-playbook ./playbooks/basic-secure.yml --user root -e "ansible_port=22" --ask-pass --ask-become-pass -i ./inventory/hosts

Then set up that user's SSH directory:

sudo mkdir -p /home/your-sudo-user/.ssh
sudo touch /home/your-sudo-user/.ssh/authorized_keys
sudo chmod 700 /home/your-sudo-user/.ssh
sudo chmod 600 /home/your-sudo-user/.ssh/authorized_keys

Setting Up Coolify's Directory Structure

sudo mkdir -p /data/coolify/{source,ssh,applications,databases,backups,services,proxy,webhooks-during-maintenance}
sudo mkdir -p /data/coolify/ssh/{keys,mux}
sudo mkdir -p /data/coolify/proxy/dynamic

Generating and Adding an SSH Key

sudo ssh-keygen -f /data/coolify/ssh/keys/*Emails are not allowed*rnal -t ed25519 -N '' -C your-sudo-user@coolify

Add the public key to the authorized_keys file:

cat /data/coolify/ssh/keys/*Emails are not allowed* | sudo tee -a /home/your-sudo-user/.ssh/authorized_keys

Pulling Coolify's Configuration Files

sudo curl -fsSL https://cdn.coollabs.io/coolify/docker-compose.yml -o /data/coolify/source/docker-compose.yml
sudo curl -fsSL https://cdn.coollabs.io/coolify/docker-compose.prod.yml -o /data/coolify/source/docker-compose.prod.yml
sudo curl -fsSL https://cdn.coollabs.io/coolify/.env.production -o /data/coolify/source/.env
sudo curl -fsSL https://cdn.coollabs.io/coolify/upgrade.sh -o /data/coolify/source/upgrade.sh

Generating Secure Environment Values

Only run these once, on first install. Changing them later can break Coolify. Back them up somewhere safe.

sudo sed -i "s|APP_ID=.*|APP_ID=$(openssl rand -hex 16)|g" /data/coolify/source/.env
sudo sed -i "s|APP_KEY=.*|APP_KEY=base64:$(openssl rand -base64 32)|g" /data/coolify/source/.env
sudo sed -i "s|DB_PASSWORD=.*|DB_PASSWORD=$(openssl rand -base64 32)|g" /data/coolify/source/.env
sudo sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=$(openssl rand -base64 32)|g" /data/coolify/source/.env
sudo sed -i "s|PUSHER_APP_ID=.*|PUSHER_APP_ID=$(openssl rand -hex 32)|g" /data/coolify/source/.env
sudo sed -i "s|PUSHER_APP_KEY=.*|PUSHER_APP_KEY=$(openssl rand -hex 32)|g" /data/coolify/source/.env
sudo sed -i "s|PUSHER_APP_SECRET=.*|PUSHER_APP_SECRET=$(openssl rand -hex 32)|g" /data/coolify/source/.env

Permissions and Docker Setup

Set correct ownership and permissions:

sudo chown -R 9999:root /data/coolify
sudo find /data/coolify -type d -exec chmod 755 {} \;
sudo find /data/coolify -type f -exec chmod 644 {} \;
sudo chown -R your-sudo-user:your-sudo-user /home/your-sudo-user/.ssh

Create the Docker network Coolify expects:

sudo docker network create --attachable coolify

Add your user to the Docker group:

sudo usermod -aG docker your-sudo-user

Starting Coolify

sudo docker compose --env-file /data/coolify/source/.env -f /data/coolify/source/docker-compose.yml -f /data/coolify/source/docker-compose.prod.yml up -d --pull always --remove-orphans --force-recreate

Confirm it's running:

sudo docker ps

Then visit http://YOUR-SERVER-IP:8000 in your browser.

Setup your SSL Certificates

Coolify's reverse-proxy Traefik does this under the hood automatically.

In your DNS records add two A records.

A     @     your-vps-ip-address        14400
A     *     your-vps-ip-address        14400

In your Coolify dashboard go to settings in the left side column. In the input box marked URL type your https subdomain for Coolify there.

https://coolify.yourdomain.com

Traefik will automatically apply a Let's Encrypt certificate to your Coolify subdomain.

Disable Port 8000

Disable port 8000 on your VPS. If your hosting provider allows you to configure a firewall from your dashboard, disable it from there. To disable port 8000, simply write rules that allow the ports you want and block everything else.

Wrap-Up

That's a full manual Coolify install on a hardened, non-root VPS — no automated script required. From here, Coolify handles the rest: connecting your Git repos, setting up applications, and managing deployments.

If you hit issues with the automated script on a newer Ubuntu release, this manual path should get you unblocked. Questions or corrections welcome in the comments.

I Ran terraform validate Inside a Lambda. Two Things Broke.

Sat, 18 Jul 2026 20:32:28 +0000

Most agent projects that generate code evaluate it by asking another model whether the code looks correct. I did that for about a week in TerraformAgent before I got tired of it.

The failure mode is boring and predictable. The judge reads a .tf file, sees resource blocks with plausible attribute names, and says yes. The file has an undeclared variable, or a reference to a resource that does not exist, or an attribute that HashiCorp removed in provider v5. The judge has no way to know. It is pattern-matching on what Terraform usually looks like, which is exactly what the generator was doing when it produced the bug.

Terraform ships a checker. It is called terraform validate. It is deterministic, it takes about a second, and it is never wrong about syntax or references. The whole reason people reach for an LLM judge here is that running the real thing inside a Lambda is annoying. It is annoying. It is also not that hard, and this post is the parts that actually bit me.

TerraformAgent is a 6-node LangGraph pipeline that turns a natural-language infra request into Terraform. Orchestrator, researcher, parallel domain subagents, aggregator, reviewer, evaluator. The evaluator is the node I care about here.

The evaluator writes to disk and shells out

The generated code lives in state as a filename-to-content dict. To run real Terraform against it, you have to put it on a filesystem. Lambda gives you /tmp, so that is where it goes:

thread_id = state.get("thread_id", "default")
temp_dir = f"/tmp/tf_eval_{thread_id}"

if os.path.exists(temp_dir):
    shutil.rmtree(temp_dir)
os.makedirs(temp_dir, exist_ok=True)

aggregated_output = state.get("aggregated_output", {})
for filename, content in aggregated_output.items():
    filepath = os.path.join(temp_dir, filename)
    with open(filepath, "w") as f:
        f.write(content)

The thread_id in the path matters. Lambda execution environments get reused across invocations, so two runs can land in the same container. Without the thread scoping, run B validates a directory containing run A's leftovers.

Then three subprocess calls, in order:

fmt_result = subprocess.run(
    ["terraform", "fmt", "-check", "-recursive"],
    cwd=temp_dir, capture_output=True, text=True, timeout=30,
)
eval_results["terraform_fmt_pass"] = fmt_result.returncode == 0

init next, then validate only if init succeeded. Skipping that guard gives you a validate failure that is really an init failure, and the retry logic then blames the wrong thing.

if init_success:
    val_result = subprocess.run(
        ["terraform", "validate", "-no-color"],
        cwd=temp_dir, capture_output=True, text=True, timeout=60,
    )
    eval_results["terraform_validate_pass"] = val_result.returncode == 0
else:
    eval_results["terraform_validate_pass"] = None
    eval_results["terraform_validate_output"] = "skipped (init failed)"

Note the three-state result. True, False, and None. None means the check did not run. If you collapse that to False you get a retry loop chasing a validation error that was never evaluated. There is a fourth case in the fmt block for the same reason: FileNotFoundError sets the result to None with the message terraform binary not found (running locally without Docker?), because the binary only exists inside the container image and I run these tests on my laptop.

terraform init wants the network. Lambda should not.

terraform init downloads the AWS provider plugin. It is about 60 MB. Doing that on every invocation is slow, costs egress, and breaks the moment HashiCorp's release endpoint has a bad minute.

So bake it into the image at build time:

RUN mkdir -p /tmp/tf-provider-cache /opt/tf-plugins && \
    cd /tmp/tf-provider-cache && \
    printf 'terraform {\n  required_providers {\n    aws = {\n      source  = "hashicorp/aws"\n      version = "~> 5.0"\n    }\n  }\n}\n' > main.tf && \
    TF_PLUGIN_CACHE_DIR=/opt/tf-plugins terraform init -backend=false && \
    rm -rf /tmp/tf-provider-cache

ENV TF_PLUGIN_CACHE_DIR=/opt/tf-plugins

A throwaway main.tf that declares nothing but the provider requirement, one init, and the plugin lands in the cache directory.

The cache goes in /opt, not /tmp. This one cost me real time. Lambda mounts a fresh empty /tmp on every execution environment at runtime. Anything you write to /tmp during the Docker build is gone. Not stale, not partially there. Gone. /opt is part of the read-only image layers and survives to runtime.

The read-only cache breaks on version mismatch

Baking into /opt fixes the download. It introduces a second problem, and this is the part I did not see coming.

/opt is read-only at runtime. Terraform treats TF_PLUGIN_CACHE_DIR as a directory it can write to. As long as the generated code asks for a provider version matching what got baked in, Terraform reads from the cache and everyone is happy. The moment the generated code pins something else, Terraform tries to download that version into the cache dir, hits a read-only path, and fails outright. Not a slow path. A hard failure.

The fix is a copy, once per execution environment:

baked_cache = os.environ.get("TF_PLUGIN_CACHE_DIR", "/opt/tf-plugins")
writable_cache = "/tmp/tf-plugins"
if not os.path.isdir(writable_cache):
    if os.path.isdir(baked_cache):
        shutil.copytree(baked_cache, writable_cache)
    else:
        os.makedirs(writable_cache, exist_ok=True)

env = os.environ.copy()
env["TF_PLUGIN_CACHE_DIR"] = writable_cache

init_result = subprocess.run(
    ["terraform", "init", "-backend=false", "-input=false", "-no-color"],
    cwd=temp_dir, capture_output=True, text=True, timeout=120, env=env,
)

The if not os.path.isdir(writable_cache) guard is what makes this cheap. Warm containers skip the copy entirely. Cold ones pay a local filesystem copy, which is nothing next to a 60 MB download. Matching versions stay fully offline. Non-matching versions still work, they just fall back to a normal network install into a directory Terraform is allowed to write to.

That is the tradeoff I would call out in a review: I could have refused non-matching versions and kept it strictly offline, which would be faster and more predictable. I chose to degrade to a network fetch instead, because an agent that generates version = "~> 4.0" for a good reason should not hard-fail on infrastructure trivia.

The LLM judge is still there. It just answers a different question.

I want to correct something, because I have seen this framed as replacing the LLM judge, and that is not what happened.

The evaluator runs both. Mechanical checks answer "is this valid Terraform." An LLM judge answers "does this do what the user asked":

judge_prompt = f"""Task: {state.get('task', '')}

Generated Terraform code:
{json.dumps(aggregated_output)}

Does the generated code satisfy the original task? Evaluate:
1. Are all requested resources present?
2. Are the configurations correct for the stated requirements?
3. Are there any obvious omissions?

Answer strictly with JSON: {{"task_success": true/false, "reason": "...", "missing_resources": [...]}}"""

Nothing deterministic can check whether "give me a VPC with a private subnet for the database" produced the right resources. That is a semantic question and it needs a model. The point is not that LLM judges are useless. The point is that they should not be answering questions a compiler already answers.

Routing the retry

The evaluator's results feed a function that decides which domains re-run. Only the flagged ones:

is_blocking = "BLOCKING_ERROR" in review_feedback
fmt_failed = eval_results.get("terraform_fmt_pass") is False
validate_failed = eval_results.get("terraform_validate_pass") is False

if not (is_blocking or fmt_failed or validate_failed):
    return []

Two things here. is False and not falsy, so the None case does not trigger a retry. And when something failed but no specific file was named in the output, every active domain retries rather than silently returning an empty list. A retry that does nothing is worse than an expensive one.

The graph wires it as a conditional edge back to the subagents, capped at 3:

workflow.add_conditional_edges(
    "evaluator",
    should_retry_or_finish,
    {"domain_subagents": "domain_subagents", "end": END},
)

What I would do differently

The fmt output is a filename list, which makes attributing a failure to a domain easy. validate output is prose from Terraform, and I am string-matching known filenames against it. That works until a filename appears in an error message for a reason unrelated to that file being broken. Parsing terraform validate -json would give me structured diagnostics with real file and line attribution. I have not done it yet.

The retry cap of 3 is a guess. I have no data on how often a third attempt fixes something a second one did not. That is a metric I should be emitting and am not.

And the judge sees json.dumps(aggregated_output) with the entire generated codebase inline. On a large request that is a lot of tokens for one boolean.

94 tests pass on this. None of them mock terraform, because the whole point was to stop trusting a stand-in for the real thing.

Takeaway

If a real tool can answer your evaluation question, run the real tool, and save the model for the questions that have no compiler.

Repo: github.com/akashpersetti/terraform-agent

How to Start Docker for Beginners

Wed, 15 Jul 2026 00:54:55 +0000

What's Docker

Docker is a containerization platform that packages applications with all dependencies into portable utils called containers.

Learn the foundational concepts of `Docker`

Core concepts:

Image: A read-only blueprint containing app code,libraries,and environment settings.
Container: A running instance of an image.
Dockerfile: Script defining how to build an image.
Volume: Persistent storage outside the container lifecycle.
Network: Enables communication between containers.

Example: Building and Running a Container

FROM node:18
WORKDIR /app
COPY package.json ./
RUN npm install
COPY .
EXPOSE 3000
CMD ["npm", "start"]

docker build -t my-node-app

docker run -p 3000:3000 my-node-app

Managing Multi-Container Apps with Docker Compose

version: '3'
services:
 app:
   build:
   ports:
     - "3000:3000"
   depends_on:
     - mongo
 mongo:
   image: mongo
   volumes:
     - mongo-data:/data/db
volumes:
 mongo-data:

RUN with:

docker-compose up

Best Practices

Use .dockerignore to exclude unnecessary files(e.g.,.git,node_modules).
Avoid :latest tags;pin versions for stability.
Run containers as non-root for security.
Use multi-stage builds to reduce image size.
Store secrets in .env files or Docker secrets, not in images.

When to Use Docker

[Y] Consistent dev/prod environments
[N] Small static sites or quick scripts where setup overhead outweighs benefits.

Next Steps

Learn Docker networking(bridge, host, overlay)for container communication.
Explore Docker volumes for persistent data.
Integrate Docker into CI/CD pipelines for automated builds and deployments.

With these fundamentals, you can confidently containerize, run, and manage applications in any environment.

Running Apache Airflow + Docker for Free Using GitHub Codespaces

Tue, 23 Jun 2026 07:22:54 +0000

While building my ETL pipeline project, I ran into a common beginner problem:

Running Apache Airflow locally on Windows with Docker was painful.

Problems included:

Low disk space
Docker setup issues
Linux compatibility problems
Environment debugging overhead

With only ~17GB free on my laptop, running multiple Airflow containers locally became difficult.

So I moved the entire setup to GitHub Codespaces.

What Codespaces Provided

Out of the box:

Ubuntu Linux environment
Docker pre-installed
VS Code in browser
Auto-cloned GitHub repo
Port forwarding for Airflow UI

Workflow

docker-compose up

Then:

Open Airflow UI
Trigger ETL DAG
Verify successful execution ✔️

Airflow was running in ~90 seconds.

Important Security Lesson

I accidentally committed my GCP service account key once.

GitHub Secret Scanning blocked the push automatically.

Immediately added:

*.json
.env

Never commit cloud credentials.

Why This Setup Helps Beginners

Codespaces removes a huge amount of local environment friction and lets you focus more on:

Airflow orchestration
ETL pipelines
Docker workflows
Cloud integrations

If you'd like:

Beginner-friendly walkthrough → check Medium
Engineering-focused breakdown → check Hashnode

Medium: Link
Hashnode: Link

Project Repo:ETL Pipeline

DataEngineering #Docker #ApacheAirflow #GitHubCodespaces

What is Coolify? Self-Hosting with Superpowers

Thu, 18 Jun 2026 03:34:08 +0000

Introduction

In the last post, we talked about the VPS and why it is a compelling option for hosting your web applications. I mentioned a tool called Coolify that makes managing a VPS significantly easier. In this post, we are going to dive deeper into what Coolify actually is, what it does, and why I think it is one of the best tools available for developers and small teams who want the power of a VPS without the complexity of managing one from scratch.

What is Coolify?

Coolify is a free, open-source, self-hostable platform as a service — or PaaS. Think of it as your own personal Heroku or Render, but running on your own server. This means you own your infrastructure, your data, and your costs.

The best way to understand Coolify is to compare it to the alternatives. Platforms like Heroku, Render, and Railway are fully managed PaaS solutions. They abstract away all the server complexity — you push your code and it runs. The trade-off is cost and control. As your app scales, the bills grow quickly and you have limited control over the underlying infrastructure.

Coolify gives you the same developer experience — push your code and it deploys — but on a VPS that you control. You get the simplicity of a managed platform with the economics and control of a VPS.

What Does Coolify Do?

Coolify handles all the hard parts of running applications on a VPS.

Git Integration - Connect your GitHub, GitLab, or Bitbucket repository and Coolify will automatically deploy your app every time you push to your main branch. No manual deployments, no SSH commands — just push your code and it is live.
Dockerized Deployments - Every application Coolify deploys runs in a Docker container. This means your apps are isolated, portable, and consistent across environments. You do not need to know Docker deeply to use Coolify — it handles the containerization for you.
Automatic HTTPS - Coolify integrates with Let's Encrypt to automatically provision and renew SSL certificates for all your applications. Every app gets HTTPS out of the box with zero configuration on your part.
Built-in Reverse Proxy Coolify uses Traefik as its built-in reverse proxy and web server. It automatically routes traffic to the right application based on the domain name. You can run multiple applications on the same VPS and Coolify handles the routing between them.
Database Management - Coolify can deploy and manage databases alongside your applications — PostgreSQL, MySQL, MongoDB, Redis and more. You can spin up a database with a few clicks and connect it to your application without any manual configuration.
Environment Variables - Manage your environment variables securely through the Coolify dashboard. No more manually editing .env files on the server.
Monitoring and Logs - Coolify provides basic monitoring and real-time log streaming for all your applications directly from the dashboard. You can see what your app is doing without SSH-ing into the server.
Backups - Coolify supports automated database backups to S3-compatible storage. Your data is protected without any manual backup scripts.

Why Would You Use Coolify?

There are several scenarios where Coolify makes a lot of sense.

You want the economics of a VPS without the complexity.
A 6USD to 10USD per month VPS with Coolify can run multiple applications that would cost hundreds of dollars per month on Heroku, Render, or Railway. For a startup or indie developer this is a significant saving.

You want full control over your infrastructure.
With Coolify you own everything. Your data stays on your server. You choose your hosting provider. You are not locked into any platform's pricing or terms of service.

You want a great developer experience.
Coolify's dashboard is clean and intuitive. Deploying an application is genuinely just a few clicks. It does not feel like managing a server — it feels like using a modern PaaS.

You are running multiple projects.
One VPS with Coolify can host multiple applications, multiple databases, and multiple domains. Instead of paying for separate hosting for each project, you consolidate everything onto one server.

What Are the Limitations?

Coolify is not perfect for every situation. Here are some things to be aware of.

You are responsible for your server — if your VPS goes down, your apps go down. With managed platforms the provider handles up time.

Some configuration is still required — especially for custom setups, firewalls, and advanced networking.

It is self-hosted — meaning you need to keep Coolify itself updated and maintained.

Not ideal for very large scale — for enterprise applications with massive traffic you may need dedicated infrastructure beyond a single VPS.

How Do You Get Started with Coolify?

Getting Coolify up and running is surprisingly straightforward. In an upcoming post I will walk you through the complete setup — from provisioning a VPS to having Coolify installed and your first application deployed.

All you need to get started is:

• A VPS with at least 2GB RAM and 2 CPU cores 
• A domain name 
• About 30 minutes of your time

Conclusion

Coolify bridges the gap between the simplicity of managed platforms and the power and economics of a VPS. For developers and small teams who want to own their infrastructure without being overwhelmed by server management, it is genuinely one of the best tools available right now.

In an upcoming post we will get our hands dirty and set up Coolify from scratch. See you there.

References

• https://coolify.io 
• https://coolify.io/docs 
• https://github.com/coollabsio/coolify

The Pipeline Was Green for Three Weeks. It Had Been Shipping a Build That Never Compiled.

Fri, 12 Jun 2026 16:25:56 +0000

For three weeks a deployment pipeline reported every step green and shipped a build that had failed to compile on every single run. The build step ended in npm run build | tee build.log so the output could be archived. That pipe is the whole story: bash returns the exit status of the last command in a pipeline, which was tee, and tee always succeeds at copying text. The compiler's non-zero exit got thrown away the instant the pipe handed off. The error was sitting right there in build.log. GitHub Actions saw exit code 0, painted the step green, and deployed the broken artifact. Nobody read the log, because the checkmark said there was nothing to read.

That's the defining property of bash in CI, and it's why I treat pipeline scripts differently from anything I run in a terminal: a silent failure can present as success. On a server you watch a command fail in front of you. In a pipeline, a swallowed exit code produces a green checkmark over broken code, and the gap between "the logs show an error" and "the pipeline reports failure" is exactly where outages are born. I wrote the full guide because I've now been burned by every variation of this, and there's a consistent set of habits that close the gap.

There are four failure modes that are specific to CI and barely ever bite you at an interactive prompt. Exit codes swallowed by a pipe — the story above, any command | tee, command | grep, command | sort. Shell provisioning differences — ubuntu-latest gives you bash 5.x, macos-latest gives you bash 3.2 from 2007, and a script using associative arrays or ${var,,} passes on one runner and throws a syntax error on the other in the same workflow. Environment variable gaps — CI sets variables you don't control and omits ones you assume exist, and without set -u a missing $DEPLOY_TARGET becomes an empty string and does something quietly wrong. Interactive-shell assumptions — CI runs a non-interactive, non-login shell that never sources your .bashrc, so a command that works when you type it dies with command not found because the thing that defined it was never loaded.

The header that closes most of these is short, and every line earns its place:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

set -e exits the moment any command fails, so the step exits non-zero and the workflow actually registers a failure. set -u treats an unset variable as an error, so a typo'd $DPLOY_TARGET dies immediately instead of expanding to nothing and corrupting a path. set -o pipefail makes a pipeline return the first non-zero exit among its commands rather than only the last — that one flag is the direct fix for the | tee bug that ran green for three weeks.

Secrets deserve their own paragraph because CI hands you env: values and secrets: values identically — the shell can't tell them apart, the only difference is that Actions masks the secret's literal string in the log. The trap is that the moment you transform a secret (base64-decode it, slice it, interpolate it), the transformed value no longer matches the mask and prints in clear text. Validate required values up front with ${VAR:?} so a missing secret fails at startup with a clear message instead of on line 47 with a cryptic permission denied, and be very careful with set -x in any step that touches a secret.

The pipe-exit-code problem is worth one concrete tool beyond pipefail: PIPESTATUS is an array holding the exit code of every command in the last pipeline, read immediately after:

npm run build | tee build.log
build_rc="${PIPESTATUS[0]}"   # npm's code, not tee's
[[ "$build_rc" -eq 0 ]] || { echo "build failed: $build_rc" >&2; exit "$build_rc"; }

pipefail has one well-known false positive — grep returns 1 when it finds no matches, which is often fine, and under pipefail plus set -e that aborts the script. Absorb it deliberately with || true only where a non-match is genuinely acceptable, and nowhere else, because blanketing every command in || true just reinvents the silent-success problem you're trying to kill.

Docker has its own landmine: every entrypoint script must end with exec "$@". Without it, your script stays PID 1 and your app runs as a child, so when the orchestrator sends SIGTERM on docker stop or a rolling deploy, the signal hits the script, which doesn't forward it, and after the grace period the orchestrator escalates to SIGKILL — abrupt termination, dropped connections, lost in-flight work. exec "$@" replaces the shell with your app so it becomes PID 1 and receives signals directly. The guide pairs this with a wait_for dependency-check pattern and a trap, and the Bash trap & Signal Handler Builder generates the exact signal block an entrypoint needs.

Deploys get the same treatment: deploy into a fresh timestamped directory, flip a current symlink atomically with ln -sfn so traffic never sees a half-written release, keep the last several releases so rollback is just re-pointing the symlink, run a health check after the swap and fail the deploy if it doesn't pass, and stamp the git SHA into the release so "what's running right now" always has an answer. And when a step fails and the logs won't say why, set -x around just the suspect section shows you each command with its variables expanded — a doubled slash or an empty segment in the trace is usually your bug standing in plain sight.

The full guide is the field manual version of all of this — the four failure modes, the safe header, secret validation with a validate_env function, PIPESTATUS and pipefail, Docker entrypoints, the atomic-symlink deploy script with rollback and health check, debugging with set -x, and a production-ready checklist at the end: https://bashsnippets.xyz/guides/bash-scripting-for-ci-cd-pipelines

If your pipeline scripts are dying on the small stuff first — unquoted loops, bad argument parsing, missing traps — the snippet library that feeds into this guide is at https://bashsnippets.xyz

Why Every Developer Should Learn Docker in 2026

Fri, 12 Jun 2026 13:39:15 +0000

Introduction

Modern software development has changed dramatically over the last decade. Applications are no longer deployed on a single server with manual configuration. Today, developers build cloud-native applications, deploy microservices, and work across multiple environments. In this landscape, Docker has become one of the most important tools a developer can learn.

Whether you're a backend developer, frontend engineer, DevOps professional, or software architect, Docker provides a consistent way to build, package, and deploy applications. In 2026, Docker knowledge is no longer just a bonus skill—it's quickly becoming a requirement.

What is Docker?

Docker is a containerization platform that allows developers to package an application along with all its dependencies into a lightweight, portable container. These containers can run consistently across different environments, including local machines, testing servers, and production infrastructure.

Instead of worrying about operating system differences or dependency conflicts, developers can create a container once and run it anywhere.

Why Developers Love Docker
Eliminates "Works on My Machine" Problems

One of the biggest frustrations in software development occurs when code runs perfectly on one machine but fails on another.

Docker solves this by creating isolated environments that contain everything the application needs. Every team member works with the same configuration, reducing environment-related bugs.

Faster Development and Testing

Developers can spin up databases, APIs, caching systems, and entire application stacks with a few commands.

Instead of manually installing PostgreSQL, Redis, or MongoDB, developers can simply launch containers and begin working immediately.

Simplified Deployment

Docker makes deployments predictable. Since the same container used during development is deployed to production, the chances of unexpected behavior are significantly reduced.

This consistency improves reliability and speeds up release cycles.

Essential for Cloud-Native Applications

Most modern cloud platforms and orchestration systems, including Kubernetes, rely heavily on containerized workloads.

Learning Docker provides the foundation for understanding scalable cloud infrastructure and DevOps practices.

Docker and CI/CD

Continuous Integration and Continuous Deployment pipelines have become standard in software engineering.

Docker integrates seamlessly with CI/CD tools such as GitHub Actions, GitLab CI, Azure DevOps, and Jenkins. Containers allow automated pipelines to build, test, and deploy applications consistently across environments.

Organizations increasingly expect developers to understand how containers fit into automated deployment workflows.

Real-World Use Cases

Docker is used by companies of all sizes for:

Microservices architecture
API deployment
Machine learning applications
Web development environments
Automated testing
Continuous deployment pipelines
Cloud-native infrastructure

From startups to enterprise organizations, containerization has become a standard practice.

Skills Developers Should Learn

To become productive with Docker, focus on:

Docker Images
Docker Containers
Dockerfiles
Docker Compose
Container Networking
Volumes and Persistent Storage
Container Security
Basic Kubernetes Concepts

Mastering these topics provides a strong foundation for modern software deployment.

Conclusion

Docker has transformed how applications are developed and deployed. It improves consistency, simplifies collaboration, and enables scalable cloud-native architectures.

As organizations continue adopting containers and Kubernetes, Docker remains one of the most valuable skills a developer can invest in. Learning Docker today not only improves your workflow but also opens doors to DevOps, cloud engineering, and modern software architecture opportunities.

In 2026, developers who understand containers are better equipped to build, deploy, and scale software efficiently. The sooner you learn Docker, the more prepared you'll be for the future of software development.

From Dockerfile to Docker Hub: A Complete Beginner's Guide to Docker

Thu, 11 Jun 2026 10:31:28 +0000

Containerization has become a fundamental skill for DevOps Engineers, Cloud Engineers, and Software Developers.

However, many beginners learn Docker commands without understanding the complete workflow behind them.

Questions like:

What exactly is a Docker Image?
How does a Dockerfile become a running Container?
Why do we push images to Docker Hub?
How do organizations deploy the same application everywhere?

are common when starting out.

In this blog, we'll build a simple Node.js application, containerize it using Docker, run it locally, and finally push the image to Docker Hub.

By the end of this guide, you'll understand the complete Docker workflow used in real-world DevOps environments.

Docker Workflow Overview

flowchart LR
    A[Application Code] --> B[Dockerfile]
    B --> C[Docker Build]
    C --> D[Docker Image]
    D --> E[Docker Run]
    E --> F[Docker Container]
    D --> G[Docker Push]
    G --> H[Docker Hub]

This is the same workflow followed by developers and DevOps teams worldwide.

What Are We Building?

We'll create a simple Node.js application that returns:

A welcome message
Environment information
Container hostname

This helps us verify that our application is actually running inside a Docker container.

Project Structure

.
├── Dockerfile
├── app.js
└── package.json

Step 1: Create the Node.js Application

app.js

const express = require("express");
const app = express();

const PORT = process.env.PORT || 3000;
const ENV = process.env.ENV_VALUE || "No env set";
const HOSTNAME = process.env.HOSTNAME || require("os").hostname();

app.get("/", (req, res) => {
  res.json({
    message: "Hello from Simple App (Node)",
    env: ENV,
    container: HOSTNAME
  });
});

app.listen(PORT, () =>
  console.log(`Node Hello listening on ${PORT}`)
);

package.json

{
  "name": "hello-app-node",
  "version": "1.0.0",
  "main": "app.js",
  "dependencies": {
    "express": "^5.2.1"
  }
}

Application Architecture

flowchart LR
    User --> Browser
    Browser --> Container
    Container --> NodeJS
    NodeJS --> JSONResponse

Whenever a user accesses the application, the request reaches the containerized Node.js application, which returns a JSON response.

Step 2: Create the Dockerfile

A Dockerfile is simply a blueprint that tells Docker how to build an image.

FROM node:24-slim

WORKDIR /app

COPY package*.json ./

RUN npm install --production

COPY . .

EXPOSE 3000

CMD ["node", "app.js"]

Understanding the Dockerfile

Base Image

FROM node:24-slim

We start with an official lightweight Node.js image from Docker Hub.

Working Directory

WORKDIR /app

Creates and switches to the /app directory inside the container.

Copy Dependency Files

COPY package*.json ./

Copies package files first.

This is considered a Docker best practice because Docker can cache dependency layers and speed up future builds.

Install Dependencies

RUN npm install --production

Installs only production dependencies.

Copy Application Source Code

COPY . .

Copies the entire project into the container.

Expose Application Port

EXPOSE 3000

Documents that the application listens on port 3000.

Start the Application

CMD ["node", "app.js"]

Runs the Node.js application when the container starts.

What Happens During Docker Build?

flowchart TD
    A[Dockerfile]
    --> B[Pull Node Base Image]
    --> C[Create Working Directory]
    --> D[Copy package.json]
    --> E[Install Dependencies]
    --> F[Copy Application Code]
    --> G[Create Image Layers]
    --> H[Docker Image Ready]

Docker executes each instruction sequentially and creates image layers.

Step 3: Build the Docker Image

Run:

docker build -t madhavnaks/node-app .

Let's understand this command:

docker build

Builds an image from a Dockerfile.

-t

Assigns a tag to the image.

madhavnaks/node-app

Image name.

Current directory containing the Dockerfile.

After a successful build you'll see output similar to:

=> naming to docker.io/madhavnaks/node-app

Docker has now created an image locally on your machine.

Step 4: Verify the Image

To see locally available images:

docker images

Example output:

REPOSITORY                TAG       IMAGE ID       SIZE
madhavnaks/node-app       latest    42c936686000   234MB

At this point, the image exists but is not running.

Docker Image vs Docker Container

Many beginners confuse these two concepts.

Think of it like this:

Docker Image = Blueprint
Docker Container = Running Application

flowchart LR
    A[Docker Image]
    --> B[Container 1]

    A --> C[Container 2]

    A --> D[Container 3]

A single image can create multiple containers.

Step 5: Run a Container

Now let's start our application.

docker run -d --name node-app -p 3001:3000 madhavnaks/node-app

Understanding the Command

Detached Mode

-d

Runs the container in the background.

Container Name

--name node-app

Assigns a friendly name to the container.

Port Mapping

-p 3001:3000

Maps:

Host Port      → Container Port
3001           → 3000

The application listens on port 3000 inside the container but is accessible on port 3001 from your machine.

Step 6: Verify the Container

Check running containers:

docker ps

Expected output:

CONTAINER ID   IMAGE                 STATUS
10265698c978   madhavnaks/node-app   Up

Step 7: Access the Application

Open:

http://localhost:3001

Expected response:

{
  "message": "Hello from Simple App (Node)",
  "env": "No env set",
  "container": "10265698c978"
}

Notice the hostname.

The hostname corresponds to the container ID, proving the application is running inside Docker.

Before pushing images, authenticate with Docker Hub.

docker login

Example:

Login Succeeded

Docker is now authorized to push images to your repository.

Why Push Images to Docker Hub?

Docker Hub acts as a centralized registry.

flowchart LR
    A[Developer Machine]
    -->|Push| B[Docker Hub]

    B -->|Pull| C[Server]

    B -->|Pull| D[Kubernetes Cluster]

Once an image is pushed, it can be pulled and run from anywhere.

Step 9: Push the Image

Push the image to Docker Hub:

docker push madhavnaks/node-app

Example output:

latest: digest: sha256:d1081ec542f521e100bd886943c13ab7568c663b56e36200e6d846163975f979

This confirms that the image has been successfully uploaded.

Step 10: Verify on Docker Hub

Visit your Docker Hub account.

You should now see:

madhavnaks/node-app

listed under repositories.

You can even share the image with others.

Anyone can now run:

docker pull madhavnaks/node-app

docker run -p 3001:3000 madhavnaks/node-app

without needing your source code.

Real-World DevOps Workflow

In production environments, the workflow usually looks like this:

flowchart LR
    A[Developer Writes Code]
    --> B[GitHub]

    B --> C[CI/CD Pipeline]

    C --> D[Docker Build]

    D --> E[Docker Hub]

    E --> F[Kubernetes Cluster]

This is exactly how modern DevOps teams package and deploy applications.

Key Takeaways

✅ Dockerfile defines how an image should be built

✅ Docker Build creates an image

✅ Docker Run creates a container

✅ Docker Hub stores and distributes images

✅ One image can create multiple containers

✅ Containerization ensures consistency across environments

Conclusion

In this guide, we covered the complete Docker workflow from source code to Docker Hub.

We learned how to:

Create a Dockerfile
Build a Docker image
Run a container
Verify application execution
Push images to Docker Hub
Understand how images move through real-world DevOps pipelines

Mastering these Docker fundamentals is the first step toward advanced topics like Docker Compose, Kubernetes, Helm, CI/CD pipelines, and cloud-native deployments.

If you're learning DevOps, try containerizing applications in different languages such as Python, Java, Go, or .NET to strengthen your understanding of Docker.

Happy Containerizing!

How I run LocalStack without committing LOCALSTACK_AUTH_TOKEN

Tue, 09 Jun 2026 14:51:24 +0000

Using Envilder to keep the LocalStack auth token out of Git while preserving a reproducible local Docker Compose setup.

I wanted a reproducible LocalStack setup without committing LOCALSTACK_AUTH_TOKEN to the repository.

That sounds simple, but it touches a common local development problem:

How do you make a project easy to run without putting real secrets in Git?

LocalStack expects the auth token to be available through the LOCALSTACK_AUTH_TOKEN environment variable when starting it with Docker, Docker Compose, the LocalStack CLI, or CI workflows.

Since LocalStack for AWS 2026.03.0, it ships as a consolidated Docker image and requires an auth token to start, so managing LOCALSTACK_AUTH_TOKEN cleanly is now part of the normal setup path, not just a Pro-only edge case.

That token is a secret, so I did not want to:

commit it to the repository
paste it into docker-compose.yml
duplicate it across helper scripts
rely on a manual export LOCALSTACK_AUTH_TOKEN=... step every time
make the setup work only on my machine

What I wanted instead was a small, repeatable contract:

this project needs LOCALSTACK_AUTH_TOKEN
resolve it from the secret store
inject it locally when needed
do not commit the value

That is the pattern I ended up using with Envilder.

The Pattern

The idea is simple:

secret values stay in a real secret store
the repository contains only the mapping
local development generates a .env file from that mapping
Docker Compose reads the generated .env
the token never gets committed

In this case, the secret is LOCALSTACK_AUTH_TOKEN.

In another project, it could be a database password, webhook secret, API key, or service credential.

Defining the Secret Mapping

Here is a minimal envilder.json example using AWS SSM Parameter Store:

{
  "$schema": "https://envilder.com/schema/map-file.v1.json",
  "$config": {
    "provider": "aws",
    "profile": "default"
  },
  "LOCALSTACK_AUTH_TOKEN": "/envilder/localstack/auth-token"
}

This file is safe to commit because it does not contain the token.

It only says:

_To produce LOCALSTACK_AUTH_TOKEN, resolve this value from the secret store._

The actual token remains outside the repository.

Generating the Local `.env`

Before starting LocalStack, generate the local environment file:

npx envilder --map=envilder.json --envfile=.env

That produces a local .env file like this:

LOCALSTACK_AUTH_TOKEN=...

The .env file should be ignored by Git:

.env

Now the project contains the setup contract, but not the secret.

Passing the Token to LocalStack

A Docker Compose service can reference the variable as usual:

services:
  localstack:
    image: localstack/localstack:stable
    ports:
      - "4566:4566"
      - "4510-4559:4510-4559"
    environment:
      LOCALSTACK_AUTH_TOKEN: \$"{LOCALSTACK_AUTH_TOKEN:?Run npx envilder first}"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"

Docker Compose automatically reads a .env file from the project directory for variable interpolation.

If your generated env file lives somewhere else, you can pass it explicitly:

docker compose --env-file path/to/.env up

The payoff is what a new contributor sees after cloning:

npx envilder --map=envilder.json --envfile=.env
docker compose up

Two commands, no Slack message asking "where do I get the token?", no secret in Git.

Why not direnv, 1Password, or chamber?

For one developer, export LOCALSTACK_AUTH_TOKEN=... works, but it creates hidden local state the repo never documents. The interesting comparison is against the tools that already resolve secrets:

direnv loads env vars when you enter a directory, but .envrc is just shell. You still write export LOCALSTACK_AUTH_TOKEN=$(aws ssm get-parameter ...) yourself, per variable, per project. It is a loader, not a resolver, and the mapping lives in bespoke shell instead of a declared contract.
1Password op run injects secrets at runtime and is excellent, but it assumes 1Password is your store. If your secrets already live in AWS SSM or Azure Key Vault, you are adding a vendor, not removing one.
chamber is the closest match for the AWS-only case:
chamber exec service -- docker compose up reads straight from SSM. If you never leave AWS and only need secrets at the command line, chamber or a three-line script is genuinely enough.

Envilder's narrow bet is different on three points:

The mapping is an explicit name -> path contract committed as JSON, not a service prefix or shell glue.
The store is your own cloud. No third-party infrastructure holds the secret.
The same map drives the CLI here, CI, and in-process resolution through the SDKs, so local dev and runtime read one contract.

If you only ever touch AWS from a shell, you may not need it. The case shows up when you have more than one provider, more than one language, or want the same declared contract locally, in CI, and at runtime.

The Slightly Meta Part

I ran into this while working on Envilder.

Envilder uses LocalStack for integration testing.

LocalStack needs LOCALSTACK_AUTH_TOKEN.

So I used Envilder to inject the token needed to start the LocalStack environment used to test Envilder.

The tool became its own first customer, which is always a useful kind of feedback.

A Note on LocalStack Auth Tokens

LocalStack's documentation is clear that LOCALSTACK_AUTH_TOKEN should be kept confidential and should not be committed to source control.

This post is not about bypassing that requirement.

It is about treating the token like any other secret:

store it safely
resolve it when needed
avoid leaking it into Git
keep the project setup reproducible

For open source maintainers, this matters. A project can require credentials for local or CI workflows and still provide a clean setup path for contributors.

Takeaway

LOCALSTACK_AUTH_TOKEN is just one example of a broader problem.

Projects often need secrets during local development, CI/CD, tests, and runtime. The hard part is not only storing those secrets safely. It is keeping the mapping between "what the app needs" and "where the secret lives" clear and consistent.

The pattern I like is:

secret values outside Git
secret mappings inside Git
one contract for local dev, CI/CD, and runtime

That is the reason I am building Envilder.

Not to add another place to store secrets.

Just to make secret resolution explicit, repeatable, and versionable.

Running Astro in a preview container

Mon, 08 Jun 2026 16:35:17 +0000

If you've ever worked on a collection of different Node apps, you've likely encountered version conflicts. Everyone wants a different version of Node or PNPM, and your new job is trying to align them all, or managing versions daily.

That's when open-source hero Kostis Kapelonis said, "Why don't we run the preview in a container?" In fact, he didn't just say this; he also submitted a PR. I told you he's an open-source hero.

The PR added a Dockerfile and a docker-compose.yaml file to the project, which let you spin up the preview site using:

docker compose up

Once Kostis had done all the hard work, I added a small enhancement to make Astro's live preview work when you change files. That meant you could start the container and keep working while all your changes are instantly visible in the preview. That keeps the developer inner loop nice and tight.

If you want to do the same, here's how to make it happen. Once again, I added a very small cherry to Kostis' wonderfully fluffy cake, so send your adoration his way.

Add a Docker compose file

Here's the docker-compose.yml file for your Astro project. It goes in the root directory.

services:
  astro:
    build: .
    ports:
 - "3000:3000"
    volumes:
 - .:/app
 - /app/node_modules
    environment:
 - NODE_ENV=development
 - HOST=0.0.0.0
    stdin_open: true
    tty: true

This maps the volumes, with a special case for node_modules. It exposes Astro's port 3000 inside the container to port 3000 on your machine so you can open it in your browser.

The Docker file

Here's the Dockerfile, which also goes in your project's root directory.

# Use Node 20 as the base image
FROM node:20-slim

# Install pnpm globally
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable

# Set the working directory
WORKDIR /app

# Copy package files
COPY package.json pnpm-lock.yaml* ./

# Install dependencies
RUN pnpm install

# Copy the rest of the source code
COPY . .

# Expose the default Astro port
EXPOSE 3000

# Start the dev server
CMD ["pnpm", "compose:dev"]

There's an optimization here around the package files, which is why they get their own copy command. There's an extra command in the package.json file that we call here, too. It's a variation of the dev script we use, but switches out the Astro run with a slight variation (the addition of the --host flag) lets just show the important bits in this code snippet:

"scripts": {     
    "compose:dev": "npm-run-all --parallel dev:img dev:dictionary compose:dev:astro dev:watch",
    "compose:dev:astro": "astro dev --host",

The Vite config change

The final change is the one that makes the live refresh to work. This goes in your astro.config.mjs file, and I popped it right after the existing server config.

server: {
    port: 3000
}
vite: {
    server: {
        watch: {
            usePolling: true,
        },
    },
},

Spinning it up

The first time I ran this, I started things up with:

docker compose up --build

You can then stop the container with

docker compose down

If you haven't changed the container, you can start it with the faster:

docker compose up

Coder Legion - Recent posts tagged docker

How to Change the WAF Web Console Listening Port When SafeLine Stays on 9443

The misconfiguration

What to compare before you call it a port change

The screen that confirms the fix

What this check does not claim

Why does the console still open on 9443 after I edited the environment file?

Is the application port the same as the web console port?

What does MGT_PROXY change if it is not the listen port?

Which screen confirms the console port is the one I intended?

Do I need a new administrator password after correcting the port?

Why I Change the WAF Web Console Listening Port Before Turning Protection On

Set the console port before the first launch

Keep that port off the public site path

Clear the host, secrets, and login gates

Name the protection you are actually turning on

How do I change the WAF web console listening port?

Is the web console port the same as the application listen port?

What should I verify before I turn protection on?

Does a different console port require MGT_PROXY?

How do I know the protection decision worked?

How to Reset the WAF Admin Account Inside Docker

What was misconfigured

Reset the account inside the management container

The screen that confirms the fix

What not to reset by accident

Close the loop with the original mistake

Why does editing POSTGRES_PASSWORD fail to reset the console admin?

How do I know the container reset actually finished?

Which URL matches the password I just reset?

Can I reset the admin account before docker compose up finishes?

Will this admin reset delete applications or replace the database password?

Why I Run a Checklist Before Turning Protection On

Confirm the host before you trust the console

Recover the admin account while the shell still works

Decide the proxy path, then decide which controls to enable

How do I reset the WAF admin account inside Docker?

Should I turn protection on before console login works?

What has to be true before an application is actually protected?

Which controls do I leave off on the first cutover?

Does this checklist replace the install guide?

Building an ATS Resume Scorer API with FastAPI, Celery, and Docker

What it does

Tech stack

Design highlights

Source code

How to Install a WAF with the Official Linux Manager Script on a Checked Host

What does the official manager script require?

Does a finished script mean the site is already protected?

Where is the first console password documented?

When is the manual compose path the documented alternative?

Which settings are outside the automatic command?

Why I Check the Host Before the Official Linux WAF Manager Script

What does the official manager script require on Linux?

Is the web console available as soon as the script finishes?

Does installation alone proxy my existing site?

Should an ARM host use the same one-line install without extra review?

How do I remove a test install without leaving the stack running?

Why I Verify Docker Compose and SSSE3 Before a WAF Install

Does docker version replace docker compose version?

What if lscpu | grep ssse3 prints nothing?

Is x86_64 or arm64 enough by itself?

Which memory and disk numbers are in the contract?

Should the installer run before these commands pass?

How to Verify Docker Compose and SSSE3 Requirements for SafeLine WAF

Why does the guide require Docker Compose 2.0.0 or above?

What does the ssse3 CPU requirement actually mean?

Which commands confirm the CPU, memory, and disk minimums?

What is the cleanest pre-install order to follow?

What Is an NPU Actually Good For? Testing CPU vs GPU vs NPU for Frigate

💡 Why This Matters for Homelabbers

🧰 Prerequisites

🔧 Configuring Frigate with OpenVINO

📊 CPU vs GPU vs NPU: What the Testing Shows

🛡️ Security Notes

🔧 Troubleshooting

✅ Wrap Up

Related from the lab

How to Run SafeLine WAF in Docker Swarm: A Deployment Checklist

Does the official guide provide a Docker Swarm command?