Coder Legion - Recent posts tagged deployment

How to Fix an ARM64 WAF Deploy When Personal Edition Is Not Supported

Sun, 01 Nov 2026 03:46:59 +0000

An ARM64 host can meet every published dependency and still be configured as an unsupported SafeLine deployment. The concrete misconfiguration is a manual .env left on the sample values: ARCH_SUFFIX is empty, POSTGRES_IMAGE is chaitin/safeline-postgres:15.18, and the operator plans to run Personal Edition. The Deploy guide says an ARM server must set ARCH_SUFFIX=-arm and POSTGRES_IMAGE=chaitin/safeline-postgres-arm:15.18. 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 (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

Confirm the host before editing .env

SafeLine lists Linux, instruction architectures x86_64 and arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and a minimum environment of 1 core CPU, 1 GB memory, and 5 GB disk (https://docs.waf.chaitin.com/en/GetStarted/Deploy). The same page gives the checks: uname -m for instruction architecture, docker version, docker compose version, free -h, and df -h. It also lists a CPU ssse3 check with lscpu | grep ssse3. Run uname -m first. If it reports an ARM architecture, do not keep the blank ARCH_SUFFIX from the sample .env. A blank suffix is the sample default, not the ARM setting.

The Deploy guide also offers an automatic install command that requires root. This fix follows the manual path, because that is where ARCH_SUFFIX and POSTGRES_IMAGE are written by hand. Create the data directory with mkdir -p "/data/safeline", download https://waf.chaitin.com/release/latest/compose.yaml into that directory, and write .env there. The sample sets SAFELINE_DIR=/data/safeline, IMAGE_TAG=latest, MGT_PORT=9443, a Postgres password, SUBNET_PREFIX=172.22.222, IMAGE_PREFIX=chaitin, an empty ARCH_SUFFIX, an empty RELEASE, REGION=-g, and MGT_PROXY=0. On ARM, replace the architecture lines before the first launch. Set ARCH_SUFFIX=-arm and POSTGRES_IMAGE=chaitin/safeline-postgres-arm:15.18. Leave RELEASE empty unless you intentionally want the LTS build. The Deploy guide says the LTS version will no longer be maintained starting from 9.1.0-LTS (14 August 2025) and strongly recommends an upgrade to the latest version.

Generate the documented secrets in the SafeLine directory, write DETECTOR_MGMT_TOKEN, MGT_INTERNAL_TOKEN, and DETECTOR_AES_KEY into .env, and chmod 600 .env. Those steps are separate from the architecture mistake, but a correct ARM file still needs them before docker compose up -d. Also create the documented resource directories and apply the documented permissions before launch, including chmod 700 on the run, mgt, sock, and postgres data paths named in the guide, plus the documented socket link.

The edition limit is not an image-tag typo

Changing the suffix does not remove the edition limit. The Deploy guide is explicit: SafeLine installed on ARM requires a Pro license to work properly, and the Personal Edition is not supported on ARM. If the only edition you can activate is Personal Edition, correcting ARCH_SUFFIX is not enough to make that edition supported. Treat a Personal Edition plan on this host as part of the same misconfiguration, not as a tuning choice. The supported path in that document is a Pro license together with the ARM image settings.

The Deploy guide does not publish a sample denial log for a Personal Edition install on ARM. Do not treat a guessed error string as proof. Use the written requirement as the decision, then use the console screen below as proof that the corrected deploy is actually up.

The screen that confirms the fix

After ARCH_SUFFIX=-arm, the ARM Postgres image line, and a Pro license are in place, start the stack with docker compose up -d from /data/safeline. The Deploy guide says this can take several minutes. The confirmation is the web console the guide tells you to open. Browse to https://<safeline-ip>:9443/ and you should see the web console page. Then run docker exec safeline-mgt resetadmin. A successful run prints the initial username, the initial password, and a Done line. Keep that password and log in. That console page, together with those resetadmin lines, is the screen that confirms the architecture settings were applied and the service reached the documented ready state.

If the console URL does not load, re-read .env before changing anything else. The two lines that define this misconfiguration are still the ones to check: ARCH_SUFFIX must be -arm, and POSTGRES_IMAGE must be chaitin/safeline-postgres-arm:15.18. Also confirm MGT_PORT is still 9443 unless you chose another console port, because the documented URL uses that port. MGT_PROXY should stay 0 unless you are configuring a proxy for the console. Re-check uname -m if you are no longer sure the host is ARM. The architecture check and the .env lines have to agree before the console can be treated as a fixed ARM deploy.

After the console is up

SafeLine is a self-hosted WAF placed in front of a web application. The product introduction says it filters and monitors HTTP traffic and can defend 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 (https://docs.waf.chaitin.com/en/home). Core capabilities listed there include defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. The docs also state that SafeLine is production-ready. It works as a reverse proxy: clients pass through SafeLine before they reach the server, and SafeLine forwards traffic that passes policy (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Once login works, open the Applications page and click Add Application. Enter the domain, hostname, or IP, the listen port such as 80 or 443, check SSL for an HTTPS app, and set the upstream to the real address of the original app. Resolve that domain to the IP of the server where SafeLine runs. The configuration guide shows sample requests for SQL injection, XSS, path traversal, code injection, and XXE, and says a blocking page means the attack was defended. Open the console attack list and click detail for the event. That check proves protection on a live site. It does not replace the resetadmin screen that confirmed the ARM deploy itself.

Does Personal Edition run on an ARM64 SafeLine host?

No. The Deploy guide says SafeLine installed on ARM requires a Pro license to work properly, and the Personal Edition is not supported on ARM (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

Which environment lines are wrong on ARM if I keep the sample file?

ARCH_SUFFIX is empty in the sample, and the sample Postgres image is chaitin/safeline-postgres:15.18. On an ARM server those must become ARCH_SUFFIX=-arm and POSTGRES_IMAGE=chaitin/safeline-postgres-arm:15.18.

What output confirms the corrected deploy?

The web console at https://<safeline-ip>:9443/ should load, and docker exec safeline-mgt resetadmin should print the initial username, the initial password, and Done.

Is arm64 outside the published architecture list?

No. The dependency table lists instruction architectures x86_64 and arm64. The command uname -m is the documented way to view the instruction architecture before you choose ARCH_SUFFIX.

What should I verify before the first docker compose up?

Confirm Docker is 20.10.14 or above, Docker Compose is 2.0.0 or above, and the host has at least 1 core, 1 GB memory, and 5 GB disk. On ARM, also confirm the two image lines and that you are not relying on Personal Edition.

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 ARM64 Edition Limits Before Turning SafeLine On

Sun, 01 Nov 2026 03:46:28 +0000

I do not turn protection on until an ARM64 host has passed an edition check. Architecture support and edition support are different facts. The deploy guide lists both x86_64 and arm64, then states that SafeLine installed on ARM requires a Pro license to work properly and that the Personal Edition is not supported on ARM (https://docs.waf.chaitin.com/en/GetStarted/Deploy). If I treat arm64 as permission to use Personal Edition, I can finish Docker setup and still have an instance that is not allowed to do the job.

This is the checklist I run before any public cutover.

Confirm the edition before touching images

I run uname -m first, because that is the documented way to view instruction architecture. If the host is not x86_64, I treat it as an ARM deployment and stop unless a Pro license is already available. I do not infer a price, a trial, or an activation command. The deploy page states the requirement and does not document those extras, so they stay outside the decision.

Image settings come next, and only after the license gate. On an ARM server the same guide says to set ARCH_SUFFIX=-arm and POSTGRES_IMAGE=chaitin/safeline-postgres-arm:15.18. Those values select ARM builds. They do not waive the Personal Edition limit. My written rule is simple: ARM images without a confirmed Pro license means do not install, or uninstall if a test install already happened. The documented removal path is docker compose down in the SafeLine directory, then removal of that directory only when I am sure the data can go.

Prove the host meets the published minimum

Support for arm64 does not mean every small board is a safe place to put a reverse proxy. The deploy guide requires Linux, Docker 20.10.14 or above, and Docker Compose 2.0.0 or above. The minimum environment is 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must provide ssse3. I use the listed checks: docker version, docker compose version, free -h, df -h, processor lines from /proc/cpuinfo, and lscpu | grep ssse3.

I also reserve the data directory before install. SafeLine writes configuration and data there, and the guide expects at least 5 GB. The manual layout uses /data/safeline. If memory, disk, Docker, or ssse3 fails, I fix the host first. Putting a filter in front of a healthy origin on an unfit host creates an outage that looks like an attack.

Decide what on will change for clients

SafeLine is a self-hosted web application firewall. It sits in front of an application as a reverse proxy, filters and monitors HTTP and HTTPS, and blocks malicious traffic while forwarding the rest (https://docs.waf.chaitin.com/en/home). The application guide adds that it is developed based on nginx: it receives traffic for the original site, cleans malicious traffic, and forwards safe traffic upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Before I add an application, I write down the three required fields. Domain can be a domain name, a hostname, or an IP address. Port is what SafeLine will listen on, such as 80 or 443, with SSL checked for HTTPS applications. Upstream is the real address SafeLine will use to reach the origin. After those settings, the domain has to resolve to the SafeLine server. That DNS change is the moment protection is actually on for visitors. I do not make it until the upstream answers through the proxy.

I also pick controls deliberately instead of enabling every feature on the first day. 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. Separate controls cover IP-based rate limiting, a web access control list, CAPTCHA challenge, an authentication challenge that blocks visitors who do not enter the password, and dynamic protection that encrypts HTML and JavaScript on each visit. Rate limiting is described as throttling traffic that exceeds defined limits, including DoS attempts, brute-force attempts, and traffic surges. I enable the extra challenges only after a normal page load works. A password wall or a CAPTCHA on a broken upstream hides the real fault.

Choose the install path and the release channel

Automatic install is the recommended path. The English command in the deploy guide is bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en, and it requires root. I still run the edition and host gates before I paste it, because a successful script is not the same as a supported Personal Edition on ARM.

Manual install is the path I use when I want the ARM suffix visible before docker compose up -d. That path installs Docker if needed, creates /data/safeline, downloads compose.yaml, writes .env, generates the documented secrets, and fixes permissions. The console port is MGT_PORT, 9443 unless I change it. After startup I open https://<safeline-ip>:9443/ and create the first administrator with docker exec safeline-mgt resetadmin. I store that initial password before anyone else logs in.

RELEASE=-lts is a separate decision. The deploy guide says the LTS version will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and it strongly recommends upgrading to the latest version. If I am uneasy about a new release, the same page recommends upgrading about one month later. I never choose LTS as a way around the ARM Pro requirement.

Turn the proxy on, then test, then cut over

When the checks above are true, I add the application and only then move a test name to the SafeLine address. I replay the documented probes against my own domain: a SQL injection union-select, an XSS onerror payload, a path traversal toward /etc/passwd, a code-injection probe, and an XXE-style payload. A blocking page means that request was stopped. I open the console attack list and read the detail view so the block is recorded, not just displayed. I also load a known-good URL. Protection is on only when bad requests are blocked, good requests still reach the origin, and I can move DNS back if the proxy path fails.

Does Personal Edition work on ARM64?

No. The deploy guide says SafeLine on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. ARCH_SUFFIX=-arm only selects ARM images.

What host checks should pass before installation?

Linux on x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, at least 1 core, 1 GB of memory, 5 GB of disk, and ssse3. The deploy guide names uname -m, the Docker version commands, free -h, df -h, CPU info, and lscpu | grep ssse3.

What changes when protection is turned on?

Visitors reach SafeLine instead of the origin. SafeLine listens on the configured port, filters HTTP or HTTPS, and forwards safe traffic to the upstream. The application domain must resolve to the SafeLine server, so the cutover is a DNS and proxy change.

How can I test blocking without inventing new attacks?

Use the probes in the application guide, pointed at your own domain: SQL injection, XSS, path traversal, code injection, and XXE. Expect a blocking page, then confirm the event in the console attack list detail view. Also request a normal page so you know the upstream still works.

Does the LTS channel remove the ARM edition limit?

No. LTS is a release choice, set with RELEASE=-lts. Maintenance for that line stops at 9.1.0-LTS, dated 14 August 2025, and the deploy guide recommends the latest version. The Pro license requirement for ARM remains either way.

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 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

Your App Works Locally. What Changes When It Goes to Production?

Fri, 30 Oct 2026 16:18:42 +0000

Hey, Emmanuel here. While I was pondering what to write about this week, I ran into an old project of mine: Relay (A “real-time” messaging platform). Think Facebook, but without any of the stuff that makes it good, like real people and the ability to actually send friend requests. Truth be told, it’s just a badly designed message board with a fixed amount of people :( that I built to learn about Websockets.

The main thing is that I remembered the absolute nightmare it was to deploy it. It’s not that I haven’t deployed a full-stack application before. No, it’s because the “genius” that made the tutorial decided to build the frontend and backend separately and then eventually move it to the same codebase for a single deployment. He configured a single build command for both ends and a lot of shoddy fixes to get it to work.

Thanks to the experience (PTSD) I got from that project, future deployments became substantially easier. So, that gave me the idea to write about taking your app to production. After building it on your machine, what comes next?

It Works on My Machine. What's the Problem?

Having an app that works on your machine but breaks when it hits production is one of the major rites of passage for developers. When you run your app from your machine, it basically acts as a personal server to handle requests and responses. But that works for just your machine, as someone else making a request to http://localhost:5000 sends it to their own device, not yours.

So, deployment means getting your app out of your device and making it accessible to others. However, a lot, and I mean, a lot of things can easily make things spiral out of control.

While developing locally, you often know exactly where everything is, how it connects, and which configuration values it needs. Deployment forces those assumptions to become explicit. Where does the frontend run? Where does the backend run? How do they communicate? Where is the database hosted? How does the application know which URLs and credentials to use? Those are all questions you need to consider when getting your app out of development and into production.

Your App Needs a Home

Firstly, your app needs a home, which is a server that it runs on. Running it locally doesn’t allow external users on other devices to be able to send requests to your server (I know certain network configurations can let it do that, but by default, it doesn't). Therefore, you need a hosting provider, which is a platform that basically offers you a chunk of their infrastructure to run your application. The exact cloud hosting provider you choose depends on your use case, requirements, and budget. For Relay, however, I used Render (this is my go-to, as their free tier is quite generous).

As you probably know, not every part of your application lives in one place. Usually, you have the frontend of the app, which deals with the client-facing services like the UI, while the backend manages data, logic, and security. Now, the way you deploy your application depends on how you arrange the frontend and backend.

For combined deployment, the frontend is built into static files, and a server serves those files while receiving backend requests. This is actually how I first started web development, using EJS (Embedded JavaScript) alongside Express/Node.js to serve my frontend. With this arrangement, you deploy the whole thing as one, as the backend receives requests directly and serves the appropriate frontend file.

However, I eventually discovered that separate deployment was the popular choice. The frontend and backend are deployed as separate services, usually with different URLs. For Relay, I actually used this arrangement. The React frontend displayed the UI, and the backend provided the core logic, like authentication, messaging, and account creation.

So now, your frontend and backend are now deployed. However, if you used the separate deployment approach, they still need to be able to communicate with one another. So, how do we do that?

The Frontend and Backend Need to Find Each Other

It’s quite obvious that both ends of your application need to communicate to actually work. For that, we use an API (a set of rules and protocols that allows different software applications to communicate and share data with each other). During development, the backend API runs on localhost (something like http://localhost:5000/api/). Hence, the frontend sends requests to that url.

However, when deployed, both ends get live URLs. Back then, I didn’t know most of this, so I wondered why Relay didn’t work when deployed. After a few frustrating minutes, I discovered I was still sending requests to http://localhost:5000/api/ from the deployed frontend. I recommend using environment variables rather than hardcoding these paths, as it’ll be easier to switch between development and production URLs without changing your code.

Of course, there are many other things that can go wrong. In my own case, I also experienced a CORS (Cross-Origin Resource Sharing) error. Keep in mind that this is a security feature designed to stop malicious sites from secretly reading your data on other websites. Notably, tools like Postman or curl don’t enforce CORS, so your API might work during development but fail when it hits production.

Fortunately, CORS errors are straightforward to handle. All you need to do is configure your backend server to include specific HTTP response headers. Setting these headers lets you provide the live frontend URL, list the allowed methods, and even include custom headers. If, like me, you use Express/Node.js for the backend, you can do this by installing the cors package and setting it up.

Where Does Your Data Live?

More often than not, your application might need to access a database for full functionality. However, a database running locally on your development machine isn’t automatically accessible by your deployed application. For this, you use a cloud database service; Supabase, Neon, and AWS RDS can provide PostgreSQL databases, while MongoDB Atlas hosts MongoDB databases.

After setting up a database from any of these cloud providers, you get a connection string. You can then configure your backend to use this connection string for accessing the database. However, DON’T hardcode the connection details in your code; use environment variables to securely pass in the required database access credentials.

I actually used MongoDB Atlas (the tutorial made me do that :( ) while building Relay, so the connection URI was set right from the development stage.

From Localhost to a Live Application

I’ve always heard about deployment issues from other devs, but getting a firsthand experience is something else. Turns out getting an application working locally is a far different game from making it accessible, secure, and reliable once it’s live. However, as I’ve now learned, each frustrating deployment teaches a valuable lesson.

Looking back, Relay wasn't exactly my finest work, but the deployment experience taught me things I wouldn't have learned by simply following a tutorial. Take your time, understand how the different pieces fit together, and don't be afraid to troubleshoot.

CloudPloy: Deploy anywhere from your AI

Wed, 14 Oct 2026 23:17:09 +0000

CloudPloy: Deploy anywhere from your AI tool.

Add an API key. Your agent deploys from Claude Code, Cursor, or any MCP client. Bring your own Ubuntu/AWS server or provision Hetzner/DigitalOcean/AWS at cost. Flat plan for the control plane; compute at the provider's rate.

Pricing: Free forever (1 small server, 1 app). Starter $9.99 / Pro $19 / Scale $39.

How to Write to Web.config in Medium Trust

Fri, 02 Oct 2026 03:37:53 +0000

If you’re working with an older ASP.NET application running under Medium Trust, you may run into a common problem: your application can read Web.config, but attempting to modify it at runtime fails with a security or permission exception.

The important point is that Medium Trust is designed to restrict applications from modifying configuration files. Simply using Server.MapPath() and File.WriteAllText() is not a reliable solution—and in a hosted environment, it will generally be blocked by filesystem permissions or the trust policy.

What can you do?

If you need to change configuration dynamically, consider these approaches:

Store dynamic settings outside Web.config

Instead of modifying Web.config, use a data store such as a database or another configuration mechanism that your application is allowed to write to.

// Example: store application settings in a database
string value = GetSettingFromDatabase("MySetting");

Use an application-level configuration file

For settings that need to be writable, keep them in a separate file, provided your hosting environment allows your application to create and modify that file.

string path = Server.MapPath("~/App_Data/settings.xml");

File.WriteAllText(path, "Value");

App_Data is commonly used for application data because it isn't intended to be served directly to clients.

Change Web.config during deployment

If the configuration really belongs in Web.config, the safest approach is usually to modify it as part of your deployment process rather than from application code.

For example:

Your deployment process can generate or transform the appropriate configuration for each environment.

What about ConfigurationManager?

You can read configuration values normally:

string value =

ConfigurationManager.AppSettings["MySetting"];

But being able to read configuration doesn't mean the application has permission to write the physical Web.config file.

Bottom line

Under Medium Trust, don't design your application around runtime modification of Web.config. If a value needs to change while the application is running, keep that value in a writable data store or separate configuration file. If it belongs in Web.config, update it during deployment.

This approach is more secure, more predictable, and works better with hosted ASP.NET environments.

🚀 Feature Flags - The Secret Behind Safe Deployments

Sun, 06 Sep 2026 10:09:34 +0000

Shipping software used to be risky.

A new deployment could introduce bugs, break critical workflows or affect thousands (or millions) of users instantly.

For many teams, releasing software meant:

Deploying late at night 🌙
Monitoring dashboards anxiously 📊
Hoping nothing breaks 🤞

Modern engineering teams solved this problem using Feature Flags.

Feature flags allow developers to release code without immediately exposing new features to users.

Instead of deploying and hoping everything works, teams can control feature visibility dynamically.

🧠 What Are Feature Flags?

A Feature Flag (also called a Feature Toggle) is a mechanism that enables or disables functionality in an application without deploying new code.

In simple terms:

if feature_flag_enabled:
    show_new_feature()
else:
    use_old_behavior()

The application contains both code paths, but the feature flag decides which one runs.

This allows developers to separate deployment from release.

Key idea:

Deployment → Shipping code to production
Release → Making the feature available to users

Feature flags allow these two processes to happen independently.

🎯 Why Feature Flags Matter

Feature flags dramatically reduce the risk of releasing software.

Without Feature Flags

Deploy → Feature immediately live

If something breaks, the only option is rollback.

With Feature Flags

Deploy → Feature disabled → Enable gradually

If something goes wrong, simply turn the feature off.

No redeployment required.

Benefits of Feature Flags

Feature flags enable:

✅ Safer releases
✅ Gradual rollouts
✅ Instant rollback
✅ Production testing
✅ Controlled experiments

🛒 Real-World Example

Imagine launching a new checkout system for an e-commerce platform.

Without Feature Flags

Deploy new checkout → All users see it

If checkout fails → Revenue stops immediately 💥

With Feature Flags

Deploy new checkout → Feature disabled
Enable for 5% users
Monitor metrics
Gradually increase rollout

If problems appear, the feature can be disabled instantly.

🧩 Types of Feature Flags

Not all feature flags are used for the same purpose.

Understanding their types helps design systems properly.

1️⃣ Release Flags

Used to gradually release new features.

Example:

new_checkout_enabled

Purpose:

Control feature rollout
Reduce release risk

Release flags are usually temporary and removed once the feature is stable.

2️⃣ Experiment Flags (A/B Testing)

Used for product experiments.

Example:

checkout_variant_A
checkout_variant_B

Users may see different versions of a feature.

Metrics measured include:

📈 Conversion rate
📊 Engagement
🔁 Retention

3️⃣ Operational Flags

Used to control system behavior during incidents.

Example:

disable_recommendation_engine

If a system starts failing, the feature can be disabled instantly.

Operational flags are useful during production outages.

4️⃣ Permission Flags

Used to control access based on user roles.

Example:

admin_dashboard_enabled

Only certain users or roles see the feature.

This is commonly used for:

internal tools
beta programs
admin dashboards

⚙️ Feature Flags vs Configuration Flags

These concepts are often confused.

Feature Flags

Used to control product functionality.

Characteristics:

Temporary
Used for rollouts
Tied to releases

Example:

enable_new_upload_ui = true

Configuration Flags

Used to control system configuration.

Characteristics:

Usually permanent
Not tied to releases

Example:

max_upload_size = 20MB

Understanding this difference prevents misuse of feature flags.

🧪 Simple Implementation Example (Go)

Here is a simple feature flag example in Go:

type FeatureFlags struct {
    NewCheckout bool
}

func Checkout(flags FeatureFlags) {
    if flags.NewCheckout {
        newCheckoutFlow()
    } else {
        oldCheckoutFlow()
    }
}

Feature flag values may come from:

configuration files
environment variables
databases
remote config services

🌐 Remote Feature Flag Systems

In production, feature flags are often managed remotely.

Popular platforms include:

LaunchDarkly
Split
Flagsmith

These systems allow teams to:

toggle features instantly ⚡
target specific users 🎯
monitor rollout metrics 📊

No redeployment required.

📈 Gradual Rollouts

One of the most powerful capabilities of feature flags is progressive rollout.

Example rollout strategy:

1% users → monitor
10% users → monitor
50% users → monitor
100% users → full release

This dramatically reduces release risk.

Problems can be detected before the feature reaches everyone.

🎯 Targeted Rollouts

Feature flags can also target specific user segments.

Examples:

internal employees
beta testers
specific countries
premium users

Example logic:

if user.country == "US":
    enable_feature()

This enables testing directly in production environments.

🐤 Canary Releases

Feature flags are commonly used with canary releases.

A canary release exposes a feature to a small subset of users first.

This helps detect:

performance issues
unexpected errors
unusual user behavior

before rolling it out globally.

🌑 Dark Launching

Another advanced technique is Dark Launching.

The feature is deployed but hidden from users.

The system still runs the feature in the background to test performance.

Example:

recommendation_engine_running = true
recommendation_visible = false

This helps test infrastructure safely before exposing the feature.

⚠️ The Hidden Problem: Feature Flag Debt

Feature flags are powerful, but they introduce a new problem:

Feature Flag Debt

Over time, many flags remain in the codebase long after the feature is released.

Example:

if old_feature_flag:

But the feature is already permanent.

This leads to:

messy code
confusion
technical debt

Flags should be removed once they are no longer needed.

🚨 Common Mistakes With Feature Flags

Many teams misuse feature flags.

Here are common pitfalls.

1️⃣ Flag Explosion

Too many flags make systems difficult to understand.

Every flag increases system complexity.

2️⃣ Flags in Performance-Critical Paths

Checking flags in very hot paths may affect performance.

Flag evaluation should be fast and lightweight.

3️⃣ Long-Lived Release Flags

Release flags should be temporary.

Once rollout finishes, remove them.

4️⃣ Mixing Flags With Business Logic

Feature flags should control behavior, not implement complex logic.

Avoid deeply nested conditions like:

if flagA and not flagB and flagC

✅ Best Practices

Successful teams follow several important practices.

1️⃣ Treat Flags as Temporary

Every release flag should have an expiration plan.

2️⃣ Track Flag Ownership

Each flag should have an owner responsible for cleanup.

3️⃣ Monitor Feature Rollouts

Always observe metrics when enabling a feature.

Examples:

error rate
latency
user behavior

4️⃣ Use Clear Naming

Bad naming:

flag123

Better naming:

checkout_v2_release

Clear names improve maintainability.

5️⃣ Remove Flags After Release

Cleaning up unused flags keeps the codebase healthy.

⚡ Feature Flags Enable Modern DevOps

Feature flags are a key component of modern engineering practices.

They enable:

🚀 Continuous deployment
🧪 Safe experimentation
🔄 Instant rollbacks
🎯 Controlled feature releases

Instead of fearing deployments, teams can release features with confidence.

🏁 Final Thoughts

Feature flags fundamentally change how software is delivered.

They transform deployments from risky events into controlled experiments.

But like any powerful tool, they must be used carefully.

Without discipline, feature flags can create complexity and technical debt.

When implemented correctly, they become one of the most powerful tools in a developer’s toolbox.

Canary Releases: How to Stop Deploying Broken Code to Everyone

Tue, 01 Sep 2026 23:35:23 +0000

What is a Canary Release?

A canary release is a modern software deployment strategy where a newly developed version of an application is rolled out to a tiny fraction of real users before making it available to the entire user base. This technique serves as an invaluable safety mechanism to identify bugs, performance degradations, or architectural errors under real-world conditions without risking a widespread outage. If the update proves stable for this initial cohort, it is progressively rolled out to everyone else; otherwise, it is immediately rolled back with near-zero impact on the general public.

The Canary in the Coal Mine

Historically, this concept stems from a crucial mining practice: coal miners would carry a live canary down into the deep subterranean tunnels because the birds are far more sensitive to toxic, odorless gases than humans are. If the canary stopped singing or collapsed, the miners knew they had to evacuate immediately before they were affected. In the modern tech world, our "canary" is the tiny, targeted group of active users who receive the new code version first. If their software sessions begin throwing errors, crashing, or slowing down, developers receive an immediate alert and can quickly shut down the test, preventing any damage from reaching the larger population.

Why Canary Releases Matter in Daily Operations

In the daily lives of software engineers, canary releases are the difference between a peaceful workday and a high-severity, multi-hour outage. When deploying updates to systems with millions of active users, traditional "big bang" deployments—where 100% of the servers are updated simultaneously—are incredibly dangerous. No matter how much testing is done on offline staging environments, real-world user behavior and high network volumes cannot be perfectly simulated. By routing just 1% to 5% of live traffic to the new update, engineers can closely monitor system metrics like API response times, database query speeds, and error logs. If the canary group encounters an issue, only a tiny sliver of users is affected, saving the business from catastrophic financial and reputational damage.

Code Implementation: Traffic Splitting

Here is a simple Node.js-style routing mechanism that shows how traffic can be split programmatically based on a user's unique ID:

// Deterministic canary router based on user ID hashes
function getAppVersionForUser(userId) {
  const CANARY_PERCENTAGE = 5; // Route 5% of users to canary
  
  // Generate a stable hash value between 0 and 99 based on the user ID
  const userBucket = Math.abs(userId) % 100;
  
  if (userBucket < CANARY_PERCENTAGE) {
    return "v2.0.0-canary"; // The new, experimental version
  }
  
  return "v1.1.0-stable"; // The reliable, existing version
}

// Example usage:
const userA = { id: 104 }; // 104 % 100 = 4 (Canary)
const userB = { id: 250 }; // 250 % 100 = 50 (Stable)

console.log(getAppVersionForUser(userA.id)); // Outputs: v2.0.0-canary
console.log(getAppVersionForUser(userB.id)); // Outputs: v1.1.0-stable

Key Takeaway

Ultimately, canary releases remove the fear and uncertainty from the deployment pipeline. By transforming launches from high-stakes, stressful events into gradual, data-driven experiments, development teams can safely ship new code multiple times a day while maintaining robust, uninterrupted uptime for their global customer base.

Resources

GitHub Repository: react-hook-lab
react-hook-lab: npm package
Connect with me on LinkedIn: Saurav Pandey

Originally published on my blog. You can read the alternative breakdown here.

Continuous Delivery Office Hours Ep.5: Delivering database changes

Mon, 24 Aug 2026 12:57:43 +0000

In the previous episode, we talked about different service design approaches. This time, we dive deeper into database changes.

Even for teams that can effortlessly deploy their application code, database changes can be more stressful. Changing a schema is a high-stakes operation, and there are many ways to do it badly.

Read on to find out why database deployments are different from application deployments, and what techniques you can use to make them worry-free.

Watch the episode

You can watch the episode below, or read on to find some of the key discussion points.

Watch Continuous Delivery Office Hours Ep.5

Why are databases different

When you change your application's code and discover an issue, it's trivial to revert to the previous version. In rare cases where a change affects your data, there may be cleanup to do.

You can use timestamps and a one-off process to fix those rare data-mess-up instances, but they hint at something fundamentally different about database updates. They have different levels and types of risk associated with them.

If you think backups will save you from a bad database deployment, you haven't yet tried it. Sure, they prevent total data loss, but between your backup and your fix, the data moved. Often by a lot.

There are techniques to apply transactions from the backup up to the point of failure, but if your change caused an issue you needed to roll back, you probably don't want to apply those transactions automatically. Welcome to the "data remediation project".

If you added a new column or table as part of your database change and you need to roll back, you have to decide what to do with any data in those tables. Do you forget it, or do you need to keep hold of it and reapply it later when you make a new attempt to extend the schema?

Modern software teams prefer fix-forward for application issues, which are reasonably easy to roll back. Databases take rollbacks to another level.

Crucial modernization steps

Imagine you met a friend for lunch and they told you they store they application's source code on a network share, rather than in version control. You'd think it was a joke, and when you realize it's not, you'd form a strong opinion about the kind of sloppy outfit they must be running.

When we meet for lunch, what are you going to tell me about your database schema and static data? Please tell me it's all in version control, not on a network share.

You should make all database changes by updating the files in version control and deploying them like you would your application code. You progress the change through environments to ensure it works, and you avoid embarrassment caused by the application failing because someone forgot to add the new column in production.

There are further choices to make, which we'll cover next, but failing to version-control your database is unforgivable.

State-based vs migration-based approaches

On to the first choice for your database project. Do you make state-based or migration-based updates?

State-based schemas describe the desired state of the database. It will list each table with its columns, indexes, and relationships. You use a model-based tool to deploy the database, which compares your current state with the desired state and applies the changes for you.

Some state-based tools convert the differences into standard database scripts, like ALTER TABLE... scripts. Others perform migrations by creating a new table with the changes and moving the data into it. This is important if you're using a technology like replication, which prevents the model migration mechanism from working.

The alternative to state-based database updates is migration-based updates, where you write your own ALTER TABLE scripts. You keep all your scripts in version control and use a tool that applies them in order and tracks when each was applied, preventing the same script from being applied twice to the same database.

The main difference between the two is procedural. You can code-review the migration scripts on demand, but you'll need to review state-based migration scripts after your tools generate the implementation plan, which can make the review task more of a large batch.

Tooling and automation

Whichever approach you use, tooling helps it work. Many of our customers use Redgate tools as part of their deployment process to manage database schema changes, and there's value in leaning on a tool written by folks who care deeply about the problem and how to solve it.

Crucially, you shouldn't make any database changes outside of tool-based automation.

Test data management

Once you've automated your database schema and static data, it's worth considering your test data. When automated or manual acceptance tests fail, it's usually because someone unwittingly messed up the data. Prior test runs often leave data in an inconsistent state, especially if a test failure halts the run.

You can resolve this issue by automating your test data setup. Not only does this make it easy to reset the data during your build and test cycle, but it also lets you provide a self-service runbook for the test team to reset the data in their test environment whenever they need to.

There's an up-front investment in this, but I can promise that it takes fewer hours than fixing your test data a few times.

Database refactoring patterns

The final thought to ponder concerns the steps you take in changing your database schema. When you're in the habit of deploying your database and application in the same release process, you start to depend on this change coordination.

You delete a column from the database and immediately deploy the application, with all references to the deleted column removed. It looks like it works smoothly, but it's a trap.

Imagine you had a critical bug in the application and had to redeploy the previous version. Now you can't, because the previous version will try to read from a column that doesn't exist. You no longer have a quick, easy back out plan, since you have to re-add the column, and you'll also need data to put in it.

This approach also prevents you from making seamless deployments, as even if you progressively roll out the application version, the old version will error out due to the database change. You may deploy in the opposite order, application first, then database. You'll discover the same problem with new columns that the latest version expects to find in the database.

You need to decouple database and application deployments, and there's a whole book on the topic, called Refactoring Databases (Ambler, Sadalage). You can start by following the expand/contract pattern, which splits updates into steps. The principle is that you don't delete a column until the production application has no reads or writes. You add a column and don't reference it in your code until you deploy to production.

This means you can run the current version and the new version of the software against the same database, which means you can progressively roll out the new version and redeploy the prior version without touching the database.

Databases are only as hard as you make them

The database is high-risk, which is why updating it can be scary. I hope you've found this post full of practical advice for making database deployments robust and stress-free.

Database deployments, like application deployments, should be a happy time. You should be celebrating the new features and enhancements you've delivered to your users, not biting your nails and worrying that something's about to go horribly wrong.

Happy deployments!

Continuous Delivery Office Hours is a series of conversations about software delivery, with Tony Kelly, Bob Walker, and Steve Fenton.

You can find more episodes on YouTube, Apple Podcasts, and Pocket Casts.

How to Deploy Your Website for Free (Vercel, Netlify, GitHub Pages)

Fri, 14 Aug 2026 05:00:00 +0000

Introduction

Building your first project is one milestone. Actually getting it live on the internet, with a real URL you can share, is a completely different feeling — and it used to be way more complicated than it is now.

Today, deploying a frontend project is genuinely a 5-minute job with the right platform. Here are the three most beginner-friendly options and exactly how to use each one.

Option 1: Vercel (Best for React/Next.js Projects)

Vercel is built by the creators of Next.js, and it's my personal go-to for React projects.

Steps:

Push your project to a GitHub repository (see Article 7 if you need a refresher)
Go to vercel.com and sign up with your GitHub account
Click "Add New Project"
Select your repository
Vercel auto-detects your framework (React, Next.js, Vite, etc.) and sets the build settings automatically
Click "Deploy"

That's it. Within a minute or two, you get a live URL like your-project.vercel.app.

Bonus: Every time you push new code to GitHub, Vercel automatically redeploys your site. No manual re-upload, ever.

Option 2: Netlify (Great All-Rounder)

Netlify works almost identically to Vercel and is equally beginner-friendly.

Steps:

Push your project to GitHub
Go to netlify.com and sign up with GitHub
Click "Add new site" → "Import an existing project"
Select your repository
Set your build command (for a Vite React app, this is usually npm run build) and publish directory (dist)
Click "Deploy site"

You'll get a URL like your-project.netlify.app, with the same automatic redeploy behavior on every push.

Netlify extra: It has a built-in drag-and-drop deploy option too — for a plain HTML/CSS/JS site with no build step, you can literally drag your project folder into the browser and it goes live instantly.

Option 3: GitHub Pages (Simplest for Static Sites)

GitHub Pages is a solid choice for portfolio sites and static HTML/CSS/JS projects — it's what many developers use for their own portfolio (mine included).

Steps for a React (Vite) project:

Install the gh-pages package:

npm install gh-pages --save-dev

In package.json, add:

"homepage": "https://yourusername.github.io/your-repo-name",
"scripts": {
  "predeploy": "npm run build",
  "deploy": "gh-pages -d dist"
}

Run:

npm run deploy

In your GitHub repo settings, go to Pages and confirm the source is set to the gh-pages branch.

Your site goes live at yourusername.github.io/your-repo-name.

For a plain HTML/CSS/JS project (no build step):

Just push your files to GitHub, go to Settings → Pages, select your main branch as the source, and save. Done.

Vercel — Best for React and Next.js projects. Offers a free custom domain.
Netlify — Best for any frontend framework, with built-in form handling and serverless functions. Offers a free custom domain.
GitHub Pages — Best for simple static websites and portfolios. Supports a free custom domain with a little setup.

My honest recommendation: use Vercel or Netlify for client and freelance projects — they handle builds, environment variables, and redeploys more smoothly. Use GitHub Pages for personal portfolio projects where simplicity matters more than advanced features.

Common Beginner Mistakes

Forgetting to set the correct build/publish directory. For Vite projects, it's dist. For Create React App, it's build. Get this wrong and you'll see a blank page.
Hardcoding API keys directly in your code instead of using environment variables — both Vercel and Netlify let you set these securely in project settings.
Not testing the production build locally first. Run npm run build and npm run preview (Vite) before deploying, to catch build errors early.
Forgetting the homepage field for GitHub Pages — without it, your assets (CSS, images) often break after deployment.

Final Thoughts

There's no excuse to keep a finished project sitting only on your local machine anymore. Pick Vercel or Netlify, connect your GitHub repo, and you'll have a shareable, live link in minutes — something you can put directly in a portfolio, a Fiverr gig, or a job application.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

Delivering Database Changes

Wed, 22 Jul 2026 09:00:00 +0000

Tony Kelly hosts our latest episode of Continuous Delivery Office Hours, with Bob Walker and Steve Fenton.

While application code deployments have become highly automated and disciplined, database changes often remain manual, "folksy," and prone to causing messy environment drift. Find out why databases require a uniquely cautious approach due to the severe risks of data loss and the impossibility of simple rollbacks, emphasizing the need to treat database deployments with the same rigor as application code.

Listen to find out more about:

Why databases are fundamentally different
Crucial first steps for modernization
State-based versus Migration-based approaches
Tooling and Automation
Test Data Management
Database Refactoring Patterns
Real-world disaster stories

Best Hosting Platforms for Next.js in 2026: Who Actually Handles ISR & PPR Correctly?

Wed, 15 Jul 2026 10:05:54 +0000

Every "best hosting for Next.js" post you'll find says roughly the same thing: Vercel is great, Netlify is a solid alternative, Cloudflare is fast, AWS is for enterprises. None of them tell you what actually happens when you deploy a page using Incremental Static Regeneration (ISR) or Partial Prerendering (PPR) to platforms that aren't Vercel.

That's the gap this post fills. Instead of comparing dashboards and pricing pages, we're going to look at what each platform's adapter actually does with ISR and PPR — because "supported" doesn't mean the same thing everywhere. This article focuses on architecture and feature behavior rather than benchmark results, since latency varies significantly by region, workload, cache hit ratio, and deployment configuration.

The Distinction Nobody Explains: Functional vs. Performance Fidelity

This is the single most useful framing in this whole post, and it comes straight from Next.js's own platform documentation.

Tip: Next.js draws a line between two levels of platform support:

Functional fidelity — the feature works correctly. Your ISR page revalidates, your PPR shell renders.

Performance fidelity — the feature works optimally. The static shell is served from the CDN edge in milliseconds, not from a server function in another region.

A platform can have full functional fidelity for PPR (it renders correctly) while having much lower performance fidelity than Vercel (it's served from a function instead of true edge-cached HTML). Both are "PPR support" — but they perform very differently in production. Keep this distinction in mind for every platform below.

Why ISR and PPR Are Hard for Non-Vercel Platforms

Quick recap if you need it: ISR lets a static page revalidate itself in the background after a set time, without a full rebuild. PPR (the rendering mode behind Cache Components, Next.js's "use cache" model) splits a single page into a static shell plus dynamic "holes" that stream in separately.

Both features assume something most CDNs weren't built for: that cached HTML can be mutated after deployment — purged, regenerated, and partially streamed — rather than treated as an immutable file tied to one deploy. Traditional CDN deploy models (Netlify, Cloudflare Pages, AWS Amplify, and others all once worked this way) assume deployed assets never change until the next deploy. ISR and PPR break that assumption on purpose.

This is exactly why Next.js, Netlify, Cloudflare, AWS Amplify, and Google Cloud spent over a year building a shared Deployment Adapter API, which went stable in Next.js 16.2 (March 2026). Before this, most non-Vercel platforms were reverse-engineering Vercel's undocumented internal build output to support ISR at all. Now there's a public, versioned contract every platform builds against — including Vercel itself.

That context matters because it means platform support for these features is improving rapidly and consistently right now, not stagnant.

Platform-by-Platform Breakdown

Vercel

Vercel built Next.js, so unsurprisingly it has both full functional and the highest performance fidelity for ISR and PPR.

ISR: Native. Stale content serves instantly while regeneration happens in the background, with sub-second revalidation propagation across their edge network.
PPR / Cache Components: This is where the gap is biggest. PPR's design intentionally splits a response into a CDN-cacheable static shell plus a dynamically-stitched stream appended at request time. As of this writing, Vercel is the only platform that stitches that static shell and the dynamic stream together at the CDN edge itself — every other platform currently resolves PPR through a server/function layer instead of true edge stitching.

// app/products/[id]/page.tsx — works identically everywhere,
// but only Vercel currently serves the static part from true edge cache
async function getProduct(id: string) {
  "use cache";
  const res = await fetch(`https://api.example.com/products/${id}`);
  return res.json();
}

Best for: teams who want zero deployment-config overhead and the fastest possible PPR/ISR performance out of the box, and don't mind paying for that convenience.

⚠️ Common Mistake: Assuming Vercel's free Hobby tier scales like its paid tier. Function execution time, image optimization, and bandwidth all meter separately — a project that feels free in development can post a real bill in production.

Netlify

Netlify's Next.js Runtime is an officially maintained adapter, tested against every new stable Next.js release.

ISR: Fully supported, including both time-based and on-demand revalidation, via Netlify's fine-grained caching primitives for the Full Route Cache and Data Cache.
PPR: Supported — Netlify provisions a serverless Function specifically to handle SSR, ISR, and PPR. This gives full functional fidelity, but the static shell isn't served straight from CDN edge cache the way Vercel's is — it still runs through that Function layer, which is the performance-fidelity gap described above.

// next.config.ts — no Netlify-specific config needed for PPR itself,
// the adapter detects and provisions the right Functions automatically
const nextConfig = {
  cacheComponents: true,
};

Best for: teams who want Vercel-like functional completeness with a different pricing model or existing Netlify infrastructure (Forms, Identity, etc.).

⚠️ Common Mistake: Pointing Next.js rewrites at static files inside public/ — Netlify's adapter doesn't support that pattern, so routes that worked locally can silently 404 in production.

Cloudflare Workers (via OpenNext)

Cloudflare doesn't have a native Next.js runtime — you deploy through the community-maintained @opennextjs/cloudflare adapter, which transforms Next.js's build output into something Workers can run.

ISR: Supported through the adapter's caching layer.
PPR: Documented as supported for the App Router, but it's newer and still maturing — Cloudflare's own docs list PPR alongside features like Node Middleware as areas with ongoing compatibility work. A dedicated, verified Cloudflare adapter built on Next.js's new stable Adapter API is in active development, which should close most remaining gaps.
The catch: image optimization needs to be delegated to Cloudflare Images or configured separately — next/image doesn't work out of the box the way it does on Vercel.

# Cloudflare-specific deploy flow
npm install @opennextjs/cloudflare
npx @opennextjs/cloudflare
npx wrangler deploy

Best for: teams already invested in Cloudflare's edge network (Workers, D1, KV, R2) who want Next.js to live in the same ecosystem, and who can tolerate being slightly behind the bleeding edge on newer caching features.

⚠️ Common Mistake: Forgetting the nodejs_compat compatibility flag in wrangler.toml / wrangler.jsonc. Without it, plenty of Next.js server dependencies simply fail at runtime with confusing errors.

AWS Amplify

Amplify has supported Next.js SSR for a while, but it's noticeably behind on the newer caching model.

ISR: Time-based revalidation works. On-demand ISR (revalidatePath / revalidateTag triggered manually) is explicitly not supported — if your app relies on on-demand revalidation, it silently won't behave as expected on Amplify.
PPR / Cache Components: Not clearly documented as supported at the time of writing. Amplify's adapter has had open compatibility issues tracking Next.js 16 support, which suggests PPR support is still catching up rather than production-proven.
Build output is also capped at 220 MB for SSR apps — easy to hit with image-heavy or dependency-heavy projects.

Best for: teams already deep in AWS infrastructure (IAM, CloudFront, existing AWS billing) who need simple SSR + scheduled ISR, and who can verify PPR behavior thoroughly before relying on it in production.

⚠️ Common Mistake: Deploying with output: "export" and expecting ISR or SSR to work. Static export disables the Next.js server runtime entirely — no SSR, no ISR, no API routes, full stop.

Railway & Render (Container/Docker Platforms)

These two get grouped together because they take the same fundamental approach: you give them a Dockerfile or a Node process, and they run it. Functionally, this means ISR and PPR work exactly as well as they do in self-hosting — because that's effectively what's happening.

Railway: Has an official Next.js + Postgres deployment guide using output: "standalone" in a Dockerfile. SSR, SSG, and ISR all work as expected since it's a real persistent Node process. PPR isn't explicitly documented but should work for the same reason — it's just next start. The bigger concern reported in 2026 production usage isn't feature support, some users have reported reliability concerns around persistent storage and deployments, so production testing is important.
Render: Supports SSR, ISR, and API routes through its Web Service deployment type, also via Docker or Git-based builds. Same story as Railway — because it's a real Node process, feature support isn't the limiting factor. Zero-downtime rolling deploys need deliberate configuration; they're not automatic the way they are on Vercel.

Best for: teams who want container-based pricing predictability without writing their own Dockerfile-to-production pipeline from scratch, and who are comfortable being early on platform maturity.

⚠️ Common Mistake: Treating Railway or Render as "set and forget" the way Vercel is. Both still require you to think about zero-downtime deploys, shared cache for multiple instances, and monitoring — that operational layer doesn't disappear just because there's no explicit Next.js adapter to configure.

Self-Hosting (Docker, VPS, Fly.io, Cloud Run)

This is the one with the cleanest answer of all of them, straight from Next.js's own documentation:

A single next start process handles every Next.js feature correctly: Server Components, ISR, PPR, Cache Components, Server Actions, Proxy, and after().

Full functional fidelity, no adapter, no caveats — because there's no translation layer between your app and the framework. The tradeoffs aren't about features; they're about who's doing the operational work.

# Minimal self-hosting Dockerfile
FROM node:22-alpine AS base
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:22-alpine AS runner
WORKDIR /app
COPY --from=base /app/.next/standalone ./
COPY --from=base /app/.next/static ./.next/static
EXPOSE 3000
CMD ["node", "server.js"]

What you give up is everything Vercel/Netlify automate for you:

Multi-instance cache coordination — if you scale beyond one server, revalidateTag() only invalidates the instance that handled the request by default. You need a shared cache handler (commonly Redis) so other instances learn about invalidations.
Streaming infrastructure — PPR's time-to-first-byte advantage depends on your reverse proxy actually supporting streaming responses. Without it, the static shell and dynamic content get buffered and sent together, which still works but quietly loses PPR's main benefit.
All the DevOps, full stop: TLS, zero-downtime deploys, observability, scaling rules.

Best for: teams with existing DevOps capacity, strict data residency or compliance requirements, or sustained traffic where Vercel's usage-based pricing starts to outpace flat compute costs.

⚠️ Common Mistake: Self-hosting without output: "standalone" in next.config.ts. Without it, your Docker image drags in the entire node_modules tree instead of a trimmed production bundle.

Quick Comparison

Platform	ISR (time-based)	ISR (on-demand)	PPR / Cache Components	Performance Fidelity
Vercel	✅ Native	✅ Native	✅ True edge-stitched shell	Highest
Netlify	✅ Via adapter	✅ Via adapter	✅ Via Function layer	High
Cloudflare Workers	✅ Via OpenNext	Maturing	Documented, still maturing	Medium
AWS Amplify	✅ Time-based only	❌ Not supported	Unclear / catching up	Medium-Low
Railway / Render	✅ (it's just Node)	✅ (it's just Node)	✅ (it's just Node)	Depends on your setup
Self-hosted	✅ Full fidelity	✅ Full fidelity	✅ Full fidelity	You configure it

So, Which One Should You Actually Use?

Default choice for most SaaS/MVP work: Vercel. The performance-fidelity gap on PPR is real, and for most projects, not having to think about adapters or streaming infrastructure is worth the premium.
Want Vercel-level functional support on a different platform or pricing model: Netlify is the most production-proven non-Vercel option for ISR and PPR today.
Already living in Cloudflare's ecosystem: Workers via OpenNext is viable, just confirm PPR behavior for your specific routes before launch — it's improving fast but newer than Netlify's support.
On AWS for compliance or org reasons: Amplify works for SSR + scheduled ISR; don't build a feature around on-demand revalidation or PPR there yet without testing thoroughly.
Want container simplicity without managing your own VPS: Railway or Render — but budget time for reliability testing, especially anything stateful.
Have DevOps capacity, compliance needs, or are past the point where usage-based pricing makes sense: self-host. Every feature works correctly by default; you're trading platform fees for engineering time.

Frequently Asked Questions

Does "supports ISR" mean it works exactly like Vercel?

Not necessarily. Use the functional vs. performance fidelity distinction from earlier in this post — most platforms now have functional support, but the experience (latency, edge caching, revalidation propagation speed) still varies.

Is PPR available everywhere yet?

Functionally, on most major platforms — yes. With the same performance characteristics as Vercel — no, not yet. Vercel currently has unique edge-stitching infrastructure that other platforms haven't replicated.

Will the new Adapter API make all platforms equal eventually?

It makes them correct against the same shared contract, which is a big deal for portability. It doesn't automatically make them equally fast — that still depends on each platform's own CDN and edge infrastructure investment.

Is self-hosting actually cheaper?

Compute usually is. Total cost isn't always — factor in the engineering hours for setup and ongoing maintenance, not just server bills, before assuming self-hosting wins on price.

Can I switch platforms later if I start with Vercel?

Yes, especially now that the Adapter API is stable and shared across platforms. It's not zero-effort, but it's far less risky than it was before this API existed.

Platform Migration Difficulty

Move From	Difficulty
Vercel → Netlify	Low
Vercel → OpenNext	Medium
Vercel → Self-hosted	Medium
Amplify → Vercel	Low

Wrapping Up

"Best Next.js hosting" isn't really a single ranking — it's a tradeoff between performance fidelity, pricing model, and how much operational work you want to own. Vercel still leads on PPR/ISR performance specifically because it built the rendering model the rest of the ecosystem is now catching up to. Everyone else is closing that gap at different speeds, and the new shared Adapter API is exactly why that gap is closing faster in 2026 than it ever has before.

If you're deploying something today: pick based on where your team already lives, then verify ISR/PPR behavior yourself in a staging deploy rather than trusting a docs page's checkmark — the distinction between "works" and "works well" is exactly what most comparison posts skip.

Useful Resources

Continue Learning

Understanding Cloud Computing Models: Public, Private, and Hybrid Cloud

Tue, 14 Jul 2026 06:42:54 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.
One of the biggest misconceptions about cloud computing is that once you move to the cloud, the cloud provider takes care of everything.

Cloud computing has transformed how businesses build, deploy, and scale applications.

Instead of investing heavily in physical infrastructure, organizations can access computing resources on demand, paying only for what they use.

But not every cloud environment is the same.

Choosing between Public Cloud, Private Cloud, and Hybrid Cloud depends on factors such as security, compliance, performance, scalability, and cost.

Let's explore each cloud model and understand when to use them.

What Are Cloud Deployment Models?

A cloud deployment model defines where your infrastructure is hosted, who owns it, and who can access it.

The three primary deployment models are:

Public Cloud
Private Cloud
Hybrid Cloud

Each model offers different levels of flexibility, security, and operational control.

Public Cloud

A public cloud is owned and operated by a cloud provider.

Infrastructure such as servers, storage, networking, and databases are shared among multiple customers.

Popular public cloud providers include Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).

Key Characteristics

No hardware to purchase or maintain
Resources can be provisioned in minutes
Pay-as-you-go pricing
Highly scalable
Global availability

Advantages

Lower upfront costs
Rapid deployment
Automatic infrastructure maintenance
High availability
Ideal for startups and growing businesses

Limitations

Less control over infrastructure
Shared environment
Some organizations may have compliance restrictions

Best Use Cases

Web applications
Mobile backends
Development and testing
AI and machine learning workloads
Disaster recovery

Private Cloud

A private cloud is dedicated to a single organization.

The infrastructure can be hosted in the organization's own data center or managed by a third-party provider.

Unlike public cloud, resources are not shared with other organizations.

Key Characteristics

Dedicated infrastructure
Greater administrative control
Enhanced security
Custom networking and configurations

Advantages

Better compliance support
Increased data privacy
Full control over infrastructure
Custom security policies

Limitations

Higher infrastructure costs
Requires skilled administrators
Scaling can take longer

Best Use Cases

Government organizations
Healthcare systems
Banking and finance
Enterprises with strict regulatory requirements

Hybrid Cloud

A hybrid cloud combines public and private cloud environments, allowing applications and data to move between them when needed.

Organizations can keep sensitive workloads in a private cloud while using the public cloud for scalability.

Key Characteristics

Combines both deployment models
Flexible workload placement
Supports gradual cloud migration
Optimizes cost and performance

Advantages

Increased flexibility
Better business continuity
Improved disaster recovery
Cost optimization
Easier migration from on-premises systems

Limitations

More complex architecture
Requires strong networking and identity management
More monitoring and governance

Best Use Cases

Large enterprises
Seasonal traffic spikes
Backup and disaster recovery
Organizations migrating to the cloud

Quick Comparison

Feature	Public Cloud	Private Cloud	Hybrid Cloud
Ownership	Cloud provider	Single organization	Both
Cost	Low upfront	Higher	Moderate
Scalability	Excellent	Limited by hardware	Excellent
Security	Good	Very High	High
Maintenance	Provider	Organization	Shared
Flexibility	High	Moderate	Very High

Which Cloud Model Should You Choose?

There isn't a single "best" deployment model.

Choose Public Cloud if you want:

Fast deployment
Lower costs
High scalability

Choose Private Cloud if you need:

Maximum security
Regulatory compliance
Complete infrastructure control

Choose Hybrid Cloud if you want:

The best of both worlds
Flexible workload placement
A gradual path to cloud adoption

Real World Example of Cloud Computing Models

Imagine an e-commerce company.

Customer-facing website runs on the Public Cloud to handle millions of visitors during sales events.
Customer payment records are stored in a Private Cloud to meet compliance requirements.
Both environments work together through a Hybrid Cloud architecture, allowing secure data exchange while maintaining scalability.

This approach balances security, performance, and cost.

Conclusion

Cloud deployment models are not competitors—they solve different business challenges.

Public cloud focuses on speed and scalability.

Private cloud emphasizes security and control.

Hybrid cloud combines both, giving organizations the flexibility to place workloads where they make the most sense.

Understanding these models helps businesses make informed decisions as they modernize their infrastructure and prepare for future growth.

As cloud technologies continue to evolve, selecting the right deployment model becomes an important step toward building secure, scalable, and resilient applications.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

Am I Deployable?

Wed, 01 Jul 2026 09:00:00 +0000

Tony Kelly hosts our latest episode of Continuous Delivery Office Hours, with Bob Walker and Steve Fenton.

In this episode of Continuous Delivery Office Hours, we ponder how you know whether your software is deployable so you can be confident you're meeting the Continuous Delivery (CD) principle of being deployable at all times.

To ensure software is deployable, teams must shift from manual testing to automated pipelines. Automation provides immediate feedback, captures institutional knowledge, and reduces long-term costs. Strategies like the Strangler Pattern help modernize legacy code for greater reliability.

Books mentioned in this episode:

Continuous Delivery by Dave Farley and Jez Humble
Extreme Programming Explained by Kent Beck
Seeing Like a State by James C Scott
The Phoenix Project / The Unicorn Project by Gene Kim et al
Toyota Production System by Taiichi Ohno

Prioritizing Continuous Delivery

Wed, 24 Jun 2026 07:16:18 +0000

Tony Kelly hosts our first episode of Continuous Delivery Office Hours, with Bob Walker and Steve Fenton.

In this episode of Continuous Delivery Office Hours, we ponder why prioritizing Continuous Delivery (CD) is essential for managing risk. We challenge the common instinct to reduce deployment frequency after failures, using a dentist analogy to explain how delaying deployments increases pain and risk by allowing unchecked changes to accumulate.

We advocate decoupling “deployments” (moving code) from “releases” (exposing features) using trunk-based development and feature toggles, which lets you test safely in production and avoid the deadlocks of complex dependency management.

Listen now to discover:

The dentist paradox
Guts on the table
The dog and biscuit
Steering with your knees

We also mentioned Bob's book, Achieving Continuous Delivery with TPF.

Remaining deployable at all times

Mon, 22 Jun 2026 13:25:04 +0000

When you can't deploy on demand, you've lost control of your software. Risk accumulates in unreleased code, and the more changes you store in one place, the more chance they have of triggering overheads, rework, and failures. When you have blockers stopping you from going live, you'll start to accumulate dangerously high levels of risk unless you prioritize deployability.

By choosing to do work that returns software to a deployable state ahead of any other kinds of work, like feature development, you'll avoid the toxicity of tangled work batches. Instead, you can smoothly flow changes between test and production and get the feedback you need to be confident that your software works.

Crucially, if you discover a high-severity bug or security problem, there are no roadblocks to getting fixes into production. You don't need a special "expedited lane" for these changes, which means you don't skip steps that let bad changes into your codebase.

Let's take a look at problem indicators that will help you identify and fix common deployability issues. The goal of answering the deployability question is a mile marker, not the destination, but if you can't answer the question, you're going to waste time looking for landmarks!

Watch the episode

You can watch the episode below, or read on to find some of the key discussion points.

Watch Continuous Delivery Office Hours Ep.2

The awkward silence problem

When you ask your team, "Are we ready to deploy?", the correct answer is either "absolutely" or "no way". The worst possible answer is silence or confusion. If the team doesn't know whether they can deploy, they're missing the deployment pipeline that would generate the answer.

When you commit a code change, build errors should be returned to you within a couple of minutes. At the end of 5 minutes from your commit, a suite of fast-running tests should tell you if you've broken functionality or the quality attributes of your application. Dependency checks, code scanning, and other static analysis tools should have told you if you have a problem. If you have long-running tests or tests that depend on the new software version being deployed to a test environment, you should know in another 5-20 minutes if they've detected a problem.

After all these checks, you should have a version of your software running in a test environment that you have high confidence in. If someone asked you whether you're ready to deploy, you'd answer "absolutely".

Deployment automation makes sure the deployment is a non-event. It guarantees the same process is used to deploy to all environments, and makes it trivial to deploy on demand. A solid deployment pipeline contains all the checks you need to know whether you can deploy.

Manual testing is a ceiling, not a floor

Teams often treat manual testing as a foundation for verifying that a software version works. In reality, it acts more like a ceiling, limiting your ability to flow changes to production. As your software becomes more complex, the ceiling descends as the testing takes longer.

Long test cycles make you subvert your process to the speed at which you can test. You'll notice when this happens because you'll keep looping back to fix bugs and restart the test process. From the earliest change you make, through each bug list and all the re-testing, right through to the final software version, you are not deployable.

Automating your tests is the real foundation for your software. This raises the ceiling and moves the constraint away from the test cycle.

Your old code wasn't written to be tested

If your application is successful, it will have some history. Part of that history is often that it wasn't written with test automation in mind. That means you need to identify where your risk is, work out how to find the seams that will make it testable, and start adding characterizing tests.

Once some old code is wrapped with tests, it becomes far easier to change the code design, because the tests will fail if you break something.

Automation is living documentation

When developers move on, a portion of your institutional knowledge goes with them. High-quality documentation can help teams distribute this knowledge and reduce its loss, and the best kind of documentation is test automation.

Well-written automation, like tests, deployment automation, and infrastructure as code, performs useful functions while effortlessly documenting them. Because you make all changes through the living documentation, it is always up to date.

The hidden cost of undocumented knowledge becomes painfully clear when you have to deploy without the person who normally handles it. You follow their checklist carefully, confirm every step, and everything looks right; yet the deployment still fails. What you didn't know is that the checklist stopped being accurate months ago, because the person doing the deployments stopped consulting it. All the new steps they introduced lived in their head, not on paper.

The living documentation built into automation tools is especially valuable when onboarding new developers. Rather than relying on tribal knowledge passed down through conversations and shadowing, a new team member can read the test suite and understand not just what the software does, but what it's supposed to do and why certain behaviors matter. That's documentation that keeps pace with the code because it is the code.

The value of long-term sustainability

Like its Agile predecessors, Continuous Delivery values long-term sustainability. That means you invest a little more effort up front to constrain maintenance costs over the long term. Writing tests may mean a feature takes 20-25% more time to implement, but the defect density can be 91% lower than similar features not guided by tests (Microsoft VS).

You could reduce 40 hours of bug fixing to just 3.6 hours by guiding feature development with tests, and you also save on other overheads caused by escaped bugs, like reputational damage, customer churn, support costs, pinpointing and debugging, test cycles, and feature delay.

Conclusion

While it takes some effort to set up a strong deployment pipeline, knowing whether a software version is deployable pays dividends. Technical practices like test-driven development and pair programming are needed to keep software economically viable in the long term, even though they require a little more effort up front.

If you can't answer the question "Is your software deployable?", you're sure to run into trouble.

Happy deployments!

Continuous Delivery Office Hours is a series of conversations about software delivery, with Tony Kelly, Bob Walker, and Steve Fenton.

You can find more episodes on YouTube, Apple Podcasts, and Pocket Casts.

Do you separate CI and CD?

Tue, 05 May 2026 12:38:19 +0000

In a lot of setups I’ve seen, CI is responsible for everything—build, test, deploy, and even rollback.

I'm convinced that this approach is not that efficient. Even the most basic things become harder than they should be. It’s no longer immediately clear what’s actually running in production, who approved the release, or what the last stable version was. And when something goes wrong, rolling back quickly without rebuilding turns into a stressful, manual process.

The information is scattered across pipeline logs, commits, and chats.

So I'm curious how you handle this. Do you separate CI and CD? If yes, what tools do you use? Or do you keep everything inside pipelines?

Let's discuss!

Why Your Project Needs a Live Demo (Not Just GitHub) — And Where to Deploy It Free

Sat, 25 Apr 2026 05:39:44 +0000

A lot of developers build good projects…

Push code to GitHub…

And stop there.

Then during interviews, recruiters ask:

“Can I see the live project?”

And many candidates say:

“Only source code is available…”

Big mistake.

Because in many cases,

A deployed project creates a much stronger impression than source code alone.

Let’s talk about why live links matter, and where you can host projects for free

The Problem With “Only Source Code”

Let’s be honest.

Most recruiters will not:

Clone your repository
Install dependencies
Run your project locally
Debug your setup issues

They simply don’t have time.

If all you share is code…

There’s friction.

And friction hurts attention.

Why Live Demo Matters in Interviews

A live project shows:

Your project actually works
You can deploy real applications
You understand production basics
Your work is demo-ready

That signals maturity.

Not just coding ability.

It makes you look closer to a real software engineer.

Source Code Shows Skill

Live Demo Shows Execution

Huge difference.

Anyone can have a repository.

Not everyone ships.

And companies value people who ship.

Why Deploying Your Project Matters

1. It Makes Your Project Real

A project running on the internet feels like a product.

Not an assignment.

Big difference.

2. Interviewers Can Test It Instantly

Instead of saying:

“Please run the repo”

You can say:

“Here’s the live link.”

Much stronger.

3. It Shows End-to-End Knowledge

Deployment means you’ve touched:

Hosting
Domains
Environment variables
Build process
Production issues

That matters.

4. You Discover Real Bugs

Fun fact:

Many bugs appear only after deployment

Classic:

“Worked locally…”

Production:

Deployment teaches things tutorials don’t.

5. Portfolio Looks 10x Better

GitHub + live demo + README

That combo hits differently.

Free Platforms to Deploy Your Projects

And yes…

You do NOT need money.

There are amazing free options.

Frontend Hosting

Vercel

Perfect for:

React
Next.js
Frontend apps

Why developers love it:

Very easy deploy
GitHub integration
Auto deployment on push
Free SSL
Great performance

Push to GitHub → connect → deploy.

Done.

⚡ Netlify

Great for:

Static sites
Frontend apps
Portfolios

Features:

Free hosting
Forms support
Serverless functions
Simple drag and drop deploy

Very beginner friendly.

GitHub Pages

Perfect for:

Portfolio sites
Static websites
Documentation projects

Very underrated.

And free.

Full Stack / Backend Hosting

☁️ Render

Great for:

Node.js apps
APIs
Full-stack projects
Databases

Very popular for student projects.

⚡ Railway

Super developer-friendly.

Great for:

Backend apps
Databases
Full stack deployments

Very smooth experience.

Fly.io

Great if you want to experiment with modern deployments.

Especially nice for containerized apps.

Good Deployment Combos

MERN Project

Frontend → Vercel
Backend → Render
Database → MongoDB Atlas Free Tier

Free stack.

Powerful stack.

Static Portfolio

Use:

Netlify
or
GitHub Pages

Done in minutes.

Bonus: Add These to Impress Interviewers

Along with live link, add:

Demo credentials (if login needed)
Screenshots in README
Architecture diagram
Deployment instructions

Small things.

Big impact.

⚠️ Common Mistake Developers Make

They think:

“Source code is enough.”

Often…

It isn’t.

Because recruiters evaluate outcomes.

Not effort.

Real Truth

A deployed project says:

I can build

GitHub says:

I can code

Companies want both.

Final Thought

Don’t let your project stay trapped in a repository.

Ship it.

Deploy it.

Make it live.

Because a project people can use…

is always stronger than a project people can only read.

And honestly?

Sometimes a live demo can impress more than your resume

What do you use for free deployments?

Vercel?
Netlify?
Render?

Let’s discuss

WebDevelopment #Deployment #SoftwareEngineering #Projects #GitHub #Vercel #Netlify #BuildInPublic

Why CI/CD Changed Software Development Forever

Fri, 24 Apr 2026 11:13:00 +0000

There was a time when deploying software was scary.

Really scary.

Developers would write code for weeks…

Then manually deploy everything at once and pray:

“Hope nothing breaks in production.”

Sometimes it worked.

Sometimes…

Production exploded

That’s exactly the problem CI/CD helped solve.

Let’s break it down simply

Before CI/CD: Releases Were Painful

Earlier, shipping software often looked like this:

Developers wrote code for weeks
Changes piled up
Big release day arrived
Team manually deployed everything

And then:

Unexpected bugs
Broken builds
Failed deployments
Long downtime

Releasing software felt risky.

⚠️ Common Problems Before CI/CD

Without automation:

Testing was often manual
Bugs were caught late
Deployments were error-prone
Rollbacks were messy
“Works on my machine” became a lifestyle

Sound familiar?

What is CI/CD?

CI/CD stands for:

✅ Continuous Integration (CI)

Developers push code frequently.

Every change automatically:

Builds the project
Runs tests
Checks if anything broke

Problems are caught early.

Continuous Delivery / Deployment (CD)

After code passes checks:

It can be:

Prepared for release automatically
Or deployed automatically

Shipping becomes faster and safer.

What Happens in a CI/CD Pipeline?

Typical flow:

Code Push → Build → Test → Security Checks → Deploy

Simple idea.

Powerful impact.

Why This Changed Everything

Before:

❌ Big risky releases

Now:

✅ Small frequent safe releases

That changes software development completely.

⚡ Real Benefits of CI/CD

Faster Development

Developers ship features quicker.

No waiting for huge release cycles.

Better Code Quality

Automated tests catch issues early.

Less broken code reaching users.

Safer Deployments

Every deployment follows a repeatable process.

No random manual mistakes.

Faster Bug Fixes

Critical issue?

Push fix.

Pipeline runs.

Deploy.

Done.

Real-World Example

Imagine updating a payment feature.

Without CI/CD:

Manual tests
Manual deploy
High risk

With CI/CD:

Push code
Tests run automatically
Deploy safely

Huge difference.

Tools You’ve Probably Heard Of

Popular CI/CD tools:

GitHub Actions
GitLab CI/CD
Jenkins
CircleCI

Different tools.

Same mission:

Automate software delivery.

Why Modern Teams Can’t Ignore It

Today apps update constantly.

Think about:

Netflix
Amazon
Spotify

They can’t do manual deployments all day.

CI/CD makes modern scale possible.

⚠️ Is CI/CD Just for Big Companies?

No.

Even small projects benefit.

Because automation early saves pain later.

Huge lesson.

The Big Shift

CI/CD changed development from:

❌ “Deploy carefully and hope”

✅ “Deploy confidently and often”

That’s a mindset shift.

Not just a tool shift.

Final Thought

CI/CD didn’t just make deployments faster.

It changed how software gets built.

Less fear.
More automation.
Faster delivery.

And honestly…

Modern software would look very different without it

From Idea to Store Launch: How WooCommerce Development Companies Work

Wed, 11 Mar 2026 06:33:33 +0000

Launching an online store often starts with excitement, a great product idea, a vision for growth, and the hope of reaching customers worldwide. But very quickly, most business owners hit the same question: How do you actually turn an idea into a fully working online store without technical chaos, delays, or wasted investment?

Many entrepreneurs try DIY platforms or hire freelancers only to discover unexpected technical challenges, performance issues, or scalability problems later. This is where professional WooCommerce development support becomes essential. Understanding how WooCommerce development companies in India work can help you see the entire journey clearly from concept planning to a successful store launch and beyond.

This guide walks you through the real workflow followed by experienced WooCommerce teams so you know exactly what happens behind the scenes when professionals build an eCommerce store.

Understanding the Role of WooCommerce Development Companies

WooCommerce is powerful because it transforms WordPress into a flexible eCommerce platform. However, flexibility also means complexity. A successful store requires thoughtful architecture, performance optimization, secure payment integrations, and user-focused design.

WooCommerce development companies don’t simply “build websites.” They act as strategic partners who combine business understanding with technical execution. Their process typically begins long before coding starts. Agencies analyze business goals, customer behavior, and long-term scalability needs to ensure the store is built for growth rather than quick deployment.

Businesses increasingly collaborate with WooCommerce development companies in India because these teams offer a blend of technical expertise, structured workflows, and cost efficiency while maintaining global development standards.

Step One: Idea Validation and Business Discovery

Every professional WooCommerce project starts with discovery. This stage answers the most important question: What should the store actually achieve?

Instead of jumping into design, developers and strategists work closely with stakeholders to understand products, target audiences, competitors, pricing models, and operational workflows. They examine whether the store will support subscriptions, multi-vendor functionality, international shipping, or custom checkout experiences.

This phase prevents one of the most common eCommerce mistakes, building features before defining business logic. By mapping user journeys early, development teams reduce costly revisions later.

During discovery, agencies also recommend the right hosting environment, plugin ecosystem, and scalability plan. These decisions influence performance and maintenance costs long after launch.

Step Two: Planning the Store Architecture

Once the idea is validated, WooCommerce experts design the technical blueprint of the store. Think of this as creating an architectural plan before constructing a building.

The team defines product structures, category hierarchies, database organization, payment flows, and integration requirements. If a business needs ERP synchronization, CRM connectivity, or custom inventory management, these integrations are planned here.

A well-planned architecture ensures faster load times, smoother checkout experiences, and easier future upgrades. This stage is where experienced WooCommerce development companies in India stand out, as they anticipate scaling challenges early rather than reacting later.

Planning also includes SEO structure, URL hierarchy, and performance considerations so the store is optimized for search visibility from day one.

Step Three: UX Design and Store Experience Creation

Design in WooCommerce development is not just about aesthetics. It focuses on guiding customers toward purchase decisions naturally.

Designers create layouts that simplify navigation, highlight products effectively, and reduce checkout friction. User behavior research influences the placement of product filters, calls-to-action, and trust signals such as reviews and guarantees.

Instead of using generic themes, professional teams often customize or design interfaces aligned with brand identity. Mobile responsiveness receives special attention because a large percentage of eCommerce traffic comes from smartphones.

At this stage, businesses begin seeing prototypes and wireframes, allowing feedback before development begins. This collaborative approach saves time and ensures expectations align with execution.

Step Four: WooCommerce Development and Customization

Development is where the store begins to take shape technically. Developers configure WooCommerce, build custom functionalities, and integrate required plugins or APIs.

This phase includes setting up product systems, payment gateways, shipping rules, tax configurations, and customer account features. If businesses require advanced capabilities such as subscription billing or marketplace functionality, developers create custom solutions rather than relying solely on plugins.

Security and performance are also built into development workflows. Clean coding practices, optimized databases, and caching strategies ensure the store handles traffic efficiently.

Experienced WooCommerce development companies India emphasize scalability during development so businesses can add features later without rebuilding the entire system.

Step Five: Testing, Optimization, and Quality Assurance

Before launch, professional agencies conduct extensive testing. This is one of the most overlooked yet critical stages of eCommerce development.

Teams test checkout flows, payment processing, mobile responsiveness, page speed, cross-browser compatibility, and user interactions. They simulate customer journeys to identify friction points that could reduce conversions.

Performance optimization plays a major role here. Developers compress images, refine scripts, and configure caching mechanisms to improve loading speeds. Faster stores not only improve user experience but also support better search rankings. During this phase, developers also review store analytics and reporting dashboards to evaluate how products, traffic sources, and sales performance behave under testing conditions. Learning how to interpret these insights is essential for long-term optimization, and guides such as woostify explain how WooCommerce reports can be used to enhance store performance through data-driven decisions.

Security testing ensures customer data protection and compliance with industry standards.

Step Six: Store Launch and Deployment

Launching a WooCommerce store is a carefully managed process rather than simply making a site live.

Development teams migrate the store to production servers, configure backups, implement SSL certificates, and finalize analytics tracking. SEO essentials such as redirects, metadata, and indexing settings are verified to avoid ranking issues after launch.

A soft launch or staging review often occurs before the public release, allowing final adjustments. Once everything is validated, the store officially goes live.

For business owners, this moment represents the transition from concept to operational online business.

Step Seven: Post-Launch Support and Growth Optimization

The work of WooCommerce development companies does not end at launch. In fact, the most valuable phase often begins afterward.

Post-launch services include performance monitoring, plugin updates, security maintenance, and feature enhancements based on real customer behavior. Agencies analyze analytics data to improve conversion rates and customer engagement.

As businesses grow, developers help scale infrastructure, introduce automation, and optimize checkout experiences. Continuous improvement ensures the store evolves alongside market trends.

Many companies rely on long-term partnerships with WooCommerce development companies India because ongoing technical support allows internal teams to focus on marketing and business strategy instead of technical troubleshooting.

Why Businesses Choose WooCommerce Development Companies India

Global businesses increasingly outsource WooCommerce development to India due to a combination of expertise and operational efficiency. Indian development teams often work within structured project management frameworks, ensuring transparent communication and predictable delivery timelines.

Another advantage is exposure to diverse international projects. Developers gain experience across industries such as fashion, electronics, education, and subscription commerce, enabling them to apply proven solutions quickly.

Cost efficiency also allows businesses to invest more in marketing, branding, and growth initiatives rather than allocating excessive budgets to development alone.

Common Challenges Solved by Professional WooCommerce Teams

Many online stores fail not because of poor products but because of technical limitations. Slow performance, complicated checkout flows, and poor scalability can reduce conversions dramatically.

Professional WooCommerce developers address these issues proactively. They design systems that handle traffic spikes, integrate reliable payment solutions, and ensure smooth customer journeys.

By following structured workflows, agencies minimize risks that often arise from fragmented development approaches or short-term fixes.

How Long Does the Journey Usually Take?

The timeline from idea to store launch varies depending on complexity. A basic WooCommerce store may take a few weeks, while custom enterprise solutions can take several months.

However, structured workflows followed by experienced teams significantly reduce delays. Clear planning, iterative feedback, and professional testing ensure smoother execution compared to unstructured DIY builds.

The goal is not just launching quickly but launching correctly.

Conclusion

Turning an idea into a successful online store involves far more than installing WooCommerce and uploading products. It requires strategic planning, thoughtful design, scalable development, and continuous optimization.

Understanding how WooCommerce development companies operate helps businesses make informed decisions and set realistic expectations. From discovery and architecture planning to launch and long-term growth, every phase contributes to building a store that performs reliably and scales with demand.

Partnering with experienced WooCommerce development companies in India allows businesses to transform complex technical processes into a structured, manageable journey. Instead of struggling with trial and error, brands can focus on growth while experts handle the technology behind the scenes.

FAQs

1. What do WooCommerce development companies actually do?
They plan, design, develop, test, and maintain WooCommerce stores while ensuring performance, scalability, and security.

2. How long does it take to launch a WooCommerce store?
Depending on complexity, it can take anywhere from 3–4 weeks for basic stores to several months for customized solutions.

3. Why hire WooCommerce development companies in India?
Businesses benefit from technical expertise, cost efficiency, and experience working with global eCommerce projects.

4. Can WooCommerce handle large-scale online stores?
Yes, with proper optimization and architecture, WooCommerce can support high traffic and large product catalogs.

5. Do developers provide support after launch?
Most professional agencies offer ongoing maintenance, updates, and performance optimization services.

6. Is WooCommerce better than hosted eCommerce platforms?
WooCommerce offers greater flexibility and ownership, making it ideal for businesses needing customization and scalability.

Linux Permissions Mistakes That Break Deployments (And How to Avoid Them)

Mon, 02 Mar 2026 12:58:38 +0000

If you’ve ever pushed a deployment that worked perfectly on your machine but failed instantly on the server there’s a good chance Linux file permissions were involved.

Few things are as frustrating as a broken deployment caused by a simple Permission denied error. Yet, Linux permission mistakes remain one of the most common (and preventable) causes of failed deployments in production environments.

In this guide, we’ll break down the most common Linux permissions mistakes that break deployments, explain why they happen, and show you how to fix and prevent them whether you're deploying a Laravel app, a Node.js API, or managing infrastructure in a DevOps workflow.

Why Linux Permissions Matter in Deployments

Linux permissions control who can read, write, and execute files and directories. During deployments, your application needs:

Read access to configuration files
Write access to logs and cache directories
Execute access for scripts and binaries
Proper ownership for web server or process users

When any of these are misconfigured, deployments fail or worse, succeed but break at runtime.

Let’s look at the most common mistakes.

1. Using `chmod 777` as a “Quick Fix”

This is the classic mistake.

You hit a permissions error and run:

chmod -R 777 storage

Problem solved… right?

Not exactly.

Why This Breaks Things Later

It creates security vulnerabilities
It masks the real ownership issue
It can conflict with shared hosting or hardened servers
It breaks compliance policies

Instead of granting permissions to everyone, you should assign the correct owner and group.

Better Approach

Identify the web server user (often www-data, nginx, or apache) and assign ownership:

chown -R www-data:www-data storage
chmod -R 775 storage

This keeps your deployment secure and production ready.

2. Wrong File Ownership After Deployment

If you deploy using:

Git
SCP
CI/CD pipelines
Docker containers

You might accidentally assign ownership to the wrong user (like root).

When the web server tries to write to a directory owned by root, deployment breaks.

Common Scenario

Files uploaded via root
Web server runs as www-data
Application tries to write logs
❌ Permission denied

Fix

Always confirm ownership after deployment:

ls -la

If needed:

chown -R www-data:www-data /var/www/project

In CI/CD pipelines, ensure deployments run under the correct user.

3. Forgetting Execute Permission on Scripts

Deployment scripts, cron jobs, and startup files require execute permissions.

If you forget:

chmod +x deploy.sh

Your CI/CD pipeline may fail silently or throw execution errors.

Symptoms

“Permission denied” when running a script
Cron jobs not executing
Container entrypoints failing

Always verify executable files:

chmod 755 script.sh

4. Not Setting Proper Permissions for Application Directories

Frameworks like:

Laravel
Django
Node.js
WordPress

Require write access to specific folders (e.g., storage, logs, uploads, cache).

If these directories don’t have proper write permissions, you’ll see:

Session failures
Log writing errors
File upload failures
500 Internal Server Errors

Best Practice

Only grant write access to directories that need it not the entire project.

Example:

chmod -R 775 storage bootstrap/cache

Be precise, not lazy.

5. Misconfigured Permissions in Docker Containers

In containerized deployments, permissions can break when:

Volumes are mounted with host ownership
UID/GID inside the container differs from the host
Files are copied during build as root

Why This Is Common

Docker builds often run as root, but production containers should not.

Best Practice

Use a non-root user in Dockerfiles
Align container UID/GID with host user
Avoid running production containers as root

Example in Dockerfile:

RUN adduser -D appuser
USER appuser

This prevents hidden permission conflicts in production.

6. Ignoring SELinux or AppArmor (Advanced)

On hardened servers, even correct Linux permissions may not be enough.

Security layers like:

SELinux
AppArmor

Can block access despite correct ownership and chmod settings.

If permissions look correct but access still fails, check:

getenforce

You may need to adjust security contexts not just file modes.

7. Deploying Without a Permissions Strategy

Many teams fix permissions reactively.

A production minded team defines:

File ownership standards
Deployment user roles
Directory write rules
CI/CD permission handling
Docker user policies

When permissions are part of the deployment design not an afterthought errors drop dramatically.

Best Practices to Prevent Linux Permission Errors

Here’s a production safe checklist:

✅ Never use chmod 777
✅ Use correct ownership (chown)
✅ Grant minimum required permissions
✅ Separate deploy user and web server user properly
✅ Ensure scripts are executable
✅ Standardize permissions in CI/CD
✅ Avoid running containers as root
✅ Document your server permission strategy

Final Thoughts: Think Production, Not Patchwork

Linux permission mistakes are small but their impact on deployments is massive.

The difference between amateur and production ready systems often comes down to discipline:

Not rushing fixes
Understanding ownership vs. permissions
Designing deployments with security in mind

If you’ve ever fixed a deployment by randomly changing file permissions, you’re not alone. But growing as a DevOps engineer or backend developer means moving beyond guesswork into structured, secure deployment practices.

Your future self and your production servers will thank you.

If you found this helpful, share it with your team. And if you want more deep dives into DevOps, Linux, Docker, and deployment best practices, stay tuned.

Effortless Web App Deployments with GitHub Actions

Sat, 13 Dec 2025 16:33:23 +0000

Automating Production Deployments on DigitalOcean

Deploying web applications manually gets painful fast — especially once your project grows.

For azan.lk, a Laravel + React application running on a hardened DigitalOcean droplet, I moved from manual SSH-based deployments to a fully automated CI/CD pipeline using GitHub Actions.
Every push to main now builds, deploys, and optimizes the app automatically — safely and consistently.

This article gives you a practical, production-ready overview of how to automate deployments without overengineering.

⚙️ What This Covers

This guide focuses on real-world CI/CD for VPS-based deployments, not platform-locked solutions.

You’ll learn how to:

Automate deployments using GitHub Actions
Build Laravel & React outside the server
Deploy via SSH securely
Run database migrations and optimizations remotely
Keep your DigitalOcean droplet lean and stable
Eliminate repetitive SSH workflows

Perfect for portfolios, SaaS apps, client projects, or APIs running on a VPS.

Prerequisites (Important)

Before adding automation, your server must already be production-ready.

Make sure you’ve completed these first:

Server Hardening
- Non-root user
- SSH keys
- Firewall & Fail2Ban
  Fortify Your DigitalOcean Droplet: A Step-by-Step Security Guide for Ubuntu 24.04
HTTPS & SSL
- Nginx
- Let’s Encrypt
- Auto-renewal
  Unlock Free HTTPS with Let’s Encrypt SSL
Manual Deployment Setup
- Laravel + PHP-FPM
- Nginx
- MySQL
- Node & Vite
  Streamlined App Deployment on Ubuntu 24.04

Once those are done, CI/CD becomes the final layer — not a replacement.

The Problem with Traditional Deployments

A typical manual deployment looks like this:

SSH into the server
Pull latest code
Run Composer
Run NPM builds
Fix permissions
Run migrations
Hope nothing breaks

On small VPS instances, Composer and NPM can consume memory, slow the server, or even crash builds.

And doing this repeatedly?
That’s technical debt waiting to happen.

What You’ll Accomplish with CI/CD

By the end of this setup, you’ll have:

Automatic deployments on every push to main
Builds handled by GitHub, not your VPS
Secure SSH-based file sync
Zero manual server logins for deploys
Reliable, repeatable production releases

Push code → GitHub Actions runs → App goes live

Why This Approach Works

This setup is optimized for developers who:

Use VPS hosting instead of managed platforms
Want full control over infrastructure
Care about performance and stability
Prefer simple, understandable pipelines

No Kubernetes.
No overcomplicated workflows.
Just clean automation that works.

Read the Full Step-by-Step Guide

The full article includes:

Complete deploy.yml workflow
GitHub Secrets setup
SSH key best practices
Common CI/CD pitfalls (and how to avoid them)
Production-safe Artisan commands

Effortless Web App Deployments: Mastering GitHub Actions with DigitalOcean

✨ Final Thoughts

CI/CD isn’t about complexity — it’s about removing friction.

Once this pipeline is in place:

Deployments become boring (that’s good)
Servers stay fast
Mistakes drop dramatically
Your workflow scales with your project

Pair this guide with Streamlined App Deployment on Ubuntu 24.04, and your readers get a complete journey:

Manual setup → hardened server → automated production deployments

The difference between deployments and releases

Mon, 08 Dec 2025 15:20:22 +0000

In software delivery, it’s common to use the terms release and deployment to refer to the same thing: making software available to users. The terms are traditionally synonyms because they happen at the same time. However, modern software delivery practices encourage us to separate the concepts.

Let’s define the terms with more precise language and look at the practical benefits of the distinction:

Deployment is when you install a software version on an environment
Release is when you make software available to a user
You could use the word release to describe a package ready for use outside the development team. However, by referring to this as a software version, you can avoid getting into a situation where you release (verb) a release (noun). Instead, you deploy or release a software version.

Technical and business tension

When DevOps was created, it recognized a natural tension between development and operations. The development team wanted to deploy more often to get new features out, while the operations team wanted to deploy less often to keep the system stable. The goal of DevOps was to resolve this tension.

If your releases are linked to deployments, you’ll find a similar tension between development and the business. You might have had a situation where the development team wanted to deploy a software version, but the business wanted to hold back the launch for marketing activities or a trade show.

By decoupling releases from deployments, developers can deploy to production frequently and the business can decide when to launch specific features.

A timeline for change

There’s a 4 step timeline for decoupling releases from deployments in your organization:

Adopt the precise terms
Introduce the architecture
Start deploying and releasing independently
Transfer control

Let’s look at what those steps mean.

Adopt the terms

The language change is the easiest place to start. By increasing your precision when talking about deployments and releases, you can start thinking differently about the two different actions.

You also need to bring your business stakeholders along on this linguistic journey. Having a shared language between the business and technical team members reduces the amount of explanation needed when talking about the software and its deployment pipeline.

While you coach your organization in semantics, you can start the next step.

Introduce the architecture

There’s a high risk of introducing release controls that become hard to manage. Without a careful design, you could end up with conditional statements scattered through your system or with several competing release control toolsets.

That’s why your release control toolset is an architectural decision.

Most release control is done with feature toggles or feature flags.

A feature toggle is a simple on or off switch for a feature
A feature flag allows selection between different versions of a feature

You can reduce complexity by limiting how many feature controls you have and the states each control has. You should remove release controls by default once the feature’s available to all users. You can identify these regularly and remove them in the next deployment.

In some cases, you may decide to implement a long-lived release control. For example, a toggle that lets you temporarily remove a resource-heavy feature during a production incident.

Release controls can apply to all users or groups of users. You should limit the number of groups and the release controls you apply to these groups at one time. You can use group-based release controls for a canary release (where you test out a feature with a small group of early-access users) or for A/B testing two different feature implementations.

There’s helpful guidance on limiting complexity in this article on feature toggles by Pete Hodgson on Martin Fowler’s website.

Your design for release controls should include a level of audit logging. Audit logging has high value when you respond to bug reports or production incidents.

When you test your software, you should use realistic business configurations rather than trying to test every combination of release controls.

Release independently

With a release control in place, you can deploy more often with the feature switched off. You can then wait for the business to line up their launch activities and release the feature when they’re ready without needing a deployment.

You should find the introduction of the release control has resolved the tension between development and the business. However, the business still depends on an engineer to throw the switch. You can take this a step further in the final step.

Transfer control

You might decide to keep hold of the release controls while you gain confidence that everything works smoothly. In the longer term, you should make the appropriate controls available to authorized business users.

When doing this, ensure they only have release controls intended for business use. You don’t want to trigger a critical incident only to find someone accidentally switched off one of your resource-heavy features.

You should already have an audit log of release control changes. The audit log is even more vital as you extend the group of users who can make changes.

Summary

You can resolve classic developer and business tensions by separating releases and deployments. You can create a release control toolset that makes it possible to release features at runtime. You must design release control to limit the complexity and prevent conditional statements from appearing all over your code.

By gradually introducing the concept of independent releases, you can take the business people with you on the journey. They should be able to launch a feature at the push of a button, just like the development team should be able to deploy on demand.

Streamlined Production Deployment on Ubuntu 24.04

Wed, 03 Dec 2025 14:21:31 +0000

Deploying a full-stack application for production doesn’t have to be complicated — especially if you follow a structured setup. For azan.lk, a Laravel + React project backed by MySQL, I built a fully optimized, secure deploymenton Ubuntu 24.04, running on a DigitalOcean Droplet.

This post is a quick overview of what the major components you’ll handle.

⚙️ What This Covers

This deployment walkthrough is designed for modern full-stack apps and covers the full stack you’d expect in real production:

Laravel backend (PHP 8.4, FPM, Composer)
React frontend (bundled via Vite)
MySQL database (hardened & configured)
Nginx production server
Node.js + NPM via NVM
Git + SSH for secure deployments
Environment setup, permissions, and optimizations

If you’re deploying a portfolio, client project, SaaS, or API backend, this setup gives you a fast, stable, security-conscious structure.

Before Deployment: Essential Prerequisites

Make sure your droplet is secure and ready for production.
I recommend completing these two guides first:

1. Server Hardening (Must Do Before Anything)

Fortify Your DigitalOcean Droplet: A Step-by-Step Security Guide for Ubuntu 24.04
A complete walkthrough covering non-root users, SSH keys, firewall, Fail2Ban, and more.

2. Enable HTTPS (Required for Live Apps)

Fortify Your Droplet: Unlock Free HTTPS with Let’s Encrypt SSL
Includes DNS setup, Nginx configs, SSL installation, and auto-renewal.

Once both are done, your droplet is safe to host real traffic — and ready for deployment.

✨ What You’ll Accomplish

Install PHP 8.4 with all required extensions for production
Set up Composer safely using the official installer
Configure MySQL with proper users, permissions, and best practices
Install Node.js via NVM for frontend builds
Set up Git SSH keys for secure repository access
Configure application permissions for Laravel
Build and optimize your frontend assets for production
Set up Nginx with proper routing, headers, and FPM integration
Run database migrations and seeders
Troubleshoot common deployment issues like PHP errors, permissions, or SSH problems

Every step — with commands, configs, and explanations — is included in the full guide on Hashnode.

Read the Full, Detailed Guide

The complete command-by-command walkthrough — including explanations, and best practices — is available on my blog.

Read the full article here:
Streamlined App Deployment: Launch Your First Web App on Ubuntu 24.04 with DigitalOcean

The post includes every command, config file, and optimization used in the real-world deployment of azan.lk.

Why This Guide Matters

Most deployment tutorials are outdated, incomplete, or skip critical production details.
This guide focuses on:

Security (SSL, firewall, SSH hardening)
Performance (PHP-FPM tuning, Vite builds)
Stability (MySQL, permissions, proper Nginx configs)
Developer workflow (Git SSH, easy updates, reliable builds)

Ideal for developers deploying real-world projects into production.

Final Thoughts

A reliable deployment is more than just “upload code and run”:
it’s a combination of security, performance, and correct configuration.

Guide to Containerizing a Modern JavaScript SPA (Vue/Vite/React) with a Multi-Stage Nginx Build

Tue, 07 Oct 2025 17:15:59 +0000

This guide outlines the professional, multi-stage Docker strategy required to package a built Single Page Application (SPA), ensuring the final image is secure, minimal, and correctly configured to serve the application and handle remote API calls. This architecture is valid for Vue, Vite, React, Angular, or Svelte applications.

1. Multi-Stage Dockerfile: Build vs. Serve

This file uses a two-stage build to drastically reduce the final image size (eliminating Node.js and build tools) and enhance security.

# Dockerfile

# Stage 1: Build the Application (AS build)
FROM docker.io/node:20-alpine AS build

# 1. Inject API URL at build time 
ARG VITE_API_URL=http://localhost:3000/api
ENV VITE_API_URL=$VITE_API_URL

WORKDIR /app
COPY package*.json ./
RUN npm ci 
COPY . .
RUN npm run build:deploy 

# ---

# Stage 2: Serve the Application (AS final)
FROM docker.io/library/nginx:stable-alpine AS final

# 1. Custom Nginx Configuration Setup
RUN rm /etc/nginx/nginx.conf
COPY nginx-main.conf /etc/nginx/nginx.conf
COPY nginx.conf /etc/nginx/conf.d/

# 2. Grant Non-Root User Permissions (CRITICAL for security & stability)
# Fixes 'mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)'
RUN mkdir -p /var/run/nginx \
    && chown -R nginx:nginx /var/cache/nginx \
    && chown -R nginx:nginx /var/run/nginx
    
# 3. Copy only the required static files from the build stage
COPY --from=build /app/dist /usr/share/nginx/html

EXPOSE 8080

# 4. Run as Non-Root User (Security Best Practice)
USER nginx

CMD ["nginx", "-g", "daemon off;"]

2. Nginx Configuration Files (The Missing Pieces)

These custom files are necessary to resolve critical permission and port errors when running Nginx as a non-root user.

A. Main Configuration (`nginx-main.conf`)

This file replaces the default /etc/nginx/nginx.conf. It controls the Master Process directives.

# nginx-main.conf (Copied to /etc/nginx/nginx.conf)

# Fixes 'open() "/run/nginx.pid" failed (13: Permission denied)'
# This MUST be in the main context.
pid /var/run/nginx/nginx.pid; 

# Sets the user for worker processes (ignored by Dockerfile's USER, but good practice)
user  nginx; 
worker_processes  auto;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    # Include our custom server block
    include /etc/nginx/conf.d/*.conf; 
}

B. Server Block (`nginx.conf`)

This file defines how your application is served and is placed in the conf.d directory.

# nginx.conf (Copied to /etc/nginx/conf.d/nginx.conf)

server {
    # Fixes 'bind() to 0.0.0.0:80 failed (13: Permission denied)'
    # Nginx listens on a high port (>1024) which the non-root user can bind to.
    listen 8080; 
    root /usr/share/nginx/html;
    index index.html;

    # Security: Hides the Nginx version
    server_tokens off;

    # SPA Routing: Directs all unmatched requests to index.html
    location / {
        try_files $uri $uri/ /index.html;
    }

    # Security: Block access to hidden files
    location ~ /\. {
        deny all;
    }
}

3. Local Development with Podman Compose

Using a docker-compose.yaml file automates the entire process.

version: '3.8'

services:
  frontend:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        VITE_API_URL: https:// http://localhost:3000/api/v1
    
    container_name: frontend-container
    
    # Maps host's 8080 port to the container's 8080 listening port
    ports:
      - "8080:8080"
    
    image: my-frontend-app:v1.0.0
    restart: always

Essential Podman Compose Commands

Command	Action
`podman compose build`	Executes the `Dockerfile` with the specified `args`.
`podman compose up -d`	Builds (if needed) and starts the container in the background.
`podman compose ps`	Checks the running status of the service(s).
`podman compose down`	Stops and removes the container(s) and network.

4. Guide Reusability and Troubleshooting

This architecture is reusable for nearly any SPA. Just update the VITE_API_URL in docker-compose.yaml and adjust the build script (npm run build:deploy) and output folder (/app/dist) in the Dockerfile if needed.

The most critical errors encountered and resolved are:

Error Logged	Cause	Solution in this Guide
`bind() to 0.0.0.0:80 failed`	Non-root user attempting to use privileged port 80.	Change `listen` to `8080` in `nginx.conf`.
`open() "/run/nginx.pid" failed`	Non-root user lacking write permission to the default PID file location.	Add `pid /var/run/nginx/nginx.pid;` to `nginx-main.conf`.
`mkdir() "/var/cache/..." failed`	Non-root user lacking permission to Nginx cache directory.	Add `chown -R nginx:nginx /var/cache/nginx` to `Dockerfile`.

You can see the files there with a lot more remarks i made coding-remarks

5. Conclusion

By implementing this Multi-Stage Build and carefully configuring Nginx for a non-root user, you've achieved the trifecta of modern container deployment: security, stability, and speed. Every step—from moving the PID file to changing the listen port—is a direct defense against common production pitfalls and security vulnerabilities. This standardized approach is the most reliable way to ship any modern JavaScript SPA, ensuring your application moves seamlessly from local development to production. You are now equipped with the knowledge to troubleshoot the most common containerization challenges and build a robust, production-ready frontend environment.

SUPIR is Still Unchallanged Image Upscaler — Supports GPUs starting from RTX 1000 series to RTX 5000

Sun, 07 Sep 2025 07:15:52 +0000

SUPIR is Still Unchallanged Image Upscaler — Supports GPUs starting from RTX 1000 series to RTX 5000 series including Cloud GPUs like H100, A100, B200, L40S, RTX 6000 Pro and such

by Furkan Gözükara - PhD Computer Engineer, SECourses

App Download Link

You can download SUPIR app from here : https://www.patreon.com/posts/99176057

It has 1-click installers for Windows (only Python 3.10.11 and Git should be sufficient), RunPod (official Pytorch 2.2.0 template) and Massed Compute template Creator > SECourses

App Info

SUPIR: Scaling Up to Excellence: Practicing Model Scaling for Photo-Realistic Image Restoration In the Wild 1 click installer scripts.
SUPIR Sampler and Text CFG Comparison : https://imgsli.com/MjU2ODQz/2/1
Gemini 2.5 Pro prompt to get image description for free :
describe this image for sdxl. write single line prompt to regenerate it exactly same. make the prompt extremely detailed
https://aistudio.google.com/prompts/new_chat
Use Default preset for highest loyalty and Replicate preset for adding more details
Human upscale from 1024x1024 to 3072x3072 (3x upscale and total 9x resolution) with face restore comparison
https://imgsli.com/NDEzMDYx
Owl upscale from 1024x1024 to 3072x3072 (3x upscale and total 9x resolution)
https://imgsli.com/NDEzMDYy

Video Tutorials

Tutorials are older but hopefully a newer one will be made and they should be still useful

https://youtu.be/OYxVEvDf284 — Complete Guide to SUPIR Enhancing and Upscaling Images Like in Sci-Fi Movies on Your PC
https://youtu.be/6oE3diDXu5w — How To Install SUPIR On RunPod and Massed Compute
https://youtu.be/RjMJh9fAO10 — How To Install & Use SUPIR : SOTA Image Upscaler On RunPod — 1 Click Easy Install & Run

6 September 2025 Update V91

Libraries upgraded to Torch 2.8, CUDA 12.9, xFormers 0.0.33, Flash Attention 2.8.3
You don’t need to have CUDA or anything else installed and it should work with Python 3.10.11 and Git installed
When compiling libraries, I added support for all GPUs starting from RTX 1000 to 5000 series including other GPUs like A100, H100, B200, L40, etc
Compiled for TORCH_CUDA_ARCH_LIST=6.1;7.5;8.0;8.6;8.9;9.0;10.0;12.0
Downloader script is 100% improved and now it is 100x more robust even for slow connection internets
It has 100% continue feature + SHA256 hash check feature now
To upgrade libraries, extract latest zip file and overwrite files
Enter inside SUPIR folder and delete venv folder
Then run Windows_Install_or_Update.bat file
Installation process is also now way faster for Windows, RunPod and Massed Compute
To fresh install extract zip file into drive like E:\SUPIR_v91
Just execute Windows_Install_or_Update.bat file
Then once installation finished use Windows_Start_SUPIR_app.bat file
If you have RTX 2000 or 1000 series still should work but if you get error please report me and try If_Regular_Install_Fails_On_RTX_2000_or_Below_GPUs.bat
If your download of models fails for any reason, you can always run Windows_Fix_Model_Download.bat
It will resume and also hash check downloaded files

Windows Requirements

Python 3.10.11 and Git should be sufficient
If you get error also make sure to have FFmpeg, CUDA 12.9, cuDNN 9.12, C++ Tools, TensorRT and MSVC
Follow this post to install all : https://www.patreon.com/posts/111553210
Follow this video to install all along with above post : https://youtu.be/DrhUHnYfwC0

2 September 2025 Update V87

With V87 full screen image preview bug fixed
For update run Windows_Update_Version.bat

30 August 2025 Update V86

We have added the new requested features
Feature 1 : Skip already upscaled images in target folder option when doing batch processing
This is simply resume
Feature 2 : In Face options Only Face Restoration
This will apply SUPIR upscale to only face and rest of the image will be deterministic Lanczos upscale (simply exactly same when you downscale back to original resolution)
Feature 3 : Now when doing both batch and single processing, it will show extra screen
Actually this was added for batch processing but due to Gradio limitations, single processing will display too
This screen will be displayed at left top
Fix : Cancel button should work perfectly fine for Single and Batch processing now
With V86 from V85, messages displayed at the top panel fixed + improved
For update, use latest zip file, extract and overwrite, and run Windows_Update_Version.bat

27 August 2025 Update V80

New Feature : First Downscale to Match Target Upscale Size
When enabled, the image is first downscaled using high-quality Lanczos algorithm to match the target resolution (after max megapixel/resolution constraints), then upscaled by the specified factor. This can help achieve more consistent results when working with size-constrained outputs.
So lets say your input image is 2000x2000 = 4 mega pixels
You want to sharpen and increase quality with 4x upscale but that would make it 16 mega pixel which is quite not possible
So set Max Megapixels = 4
Set Upscale Size = 4
And enable First Downscale to Match Target Upscale Size checkbox
So it will first downscale image into 500x500 and then it will upscale into 2000x2000
To update just use latest zip file and run Windows_Update_Version.bat

How To Install

Download latest zip file from the attachments and extract files wherever you want to install
Double click windows_install .bat and let it install and download necessary models
Requires 12 GB VRAM without LLaVA. Tested on RTX 3060
Make sure that your VRAM usage is not bigger than 500 MB before starting the SUPIR
If you want to use LLaVA you can use our better installer : https://www.patreon.com/posts/90744385
LLaVA is not mandatory as shown in full tutorial video : https://youtu.be/PqREA6-bC3w

Please register via this link : https://vm.massedcompute.com/signup?linkId=lp_034338&sourceId=secourses&tenantId=massed-compute
We have a special coupon for all GPUs : SECourses
If you want to learn more about GPUs and prices read this link : https://www.patreon.com/posts/126671823
Select RTX A6000 or Better GPU — like L40S or A6000 ADA or A100 or H100
Then select our image SECourses from Creator dropdown
Then follow Massed_Compute_Instructions_READ.txt
Same as my any other Massed Compute installer script
Example tutorial for learn how to install and use Massed Compute
(Starts at 12:58) : https://youtu.be/KW-MHmoNcqo?si=G1WbG-Qw4ujWvOtG&t=778

RunPod (Cloud):

Please register via this link : https://get.runpod.io/955rkuppqv4h
Then follow Runpod_Instructions_READ.txt
Same as my any other RunPod installer script
Use the template written in Runpod_Instructions_READ.txt file
Example tutorial for learn how to install and use RunPod
(starts at 22:03) : https://youtu.be/KW-MHmoNcqo?si=QN8X8Sjn13ZYu-EU&t=1323

How To Use

The biggest difference making thing is under SUPIR options Text Guidance Scale
This will impact how much add new details or stay loyal to the original image
Next big thing is Sampler
EDM is more loyal to the original image but DPMPP2M can add more details
S-Churn and S-Noise doesn’t make much valuable difference but you can test
In the Advanced Options
Linear CFG and Linear Stage2 Guidance can make difference so you can try them
All generated images will be automatically saved inside outputs folder
If you also want to use LLaVA we have better LLaVA scripts which supports 4-bit, 8-bit and 16-bit loading
But even with simple captions it works great you can just type
Image comparison sliders to Test : https://imgsli.com/ , https://web-toolbox.dev/en/tools/image-compare-slider , https://www.diffchecker.com/image-compare/
Here example. All default except Linear Stage2 Guidance is enabled and set 0.5
input image : input_1.png

Basic Caption : a trex dinosaur in jurassic park
Output : basic_caption.png

Better caption : A gigantic dinosaur with sharp teeth is standing in a lush green landscape with mountains in the background. The sky is partly cloudy, and the dinosaur appears to be in motion, possibly running or lunging forward. The setting seems to be reminiscent of prehistoric or Jurassic environments, likely intended to represent the natural habitat of such a creature.
Output : better_caption.png

Camel

A family photo

Speed Means Nothing Without Real Feedback

Mon, 01 Sep 2025 11:59:56 +0000

Small batches, often ignored in the quest for speed, can help organizations respond to new conditions or knowledge and change course.

While the heavyweight era of software delivery made the mistake of placing far too much value on activity, the agile era puts too much emphasis on speed.

Speed myopia means known good things, like small batches, are framed purely in terms of making teams faster. The other benefits of small batches are ignored and lost in the hurry to optimize straight-line speed.

Small-Batch Benefits

Small batches remove the tangle of complexity that creeps in when you bring too much change together at once. It can be tempting to dismiss this as a necessary part of the process, but it sucks time and effort away from valuable activities.

When Richard Feynman was sent from Los Alamos to Oak Ridge National Laboratory to improve the safety of storage for highly explosive uranium, one key factor was how much material was stored together. Putting too much material in one place could cause it to spontaneously blow up.

Software teams need to understand that this principle applies to changes too. When there is too much change, dangerous interactions manifest themselves at each stage in the delivery process. Merging changes, testing the software, fixing the problems you discover, upgrading a data store and rolling out the new version all occur with higher risk when you batch the changes.

Software might not literally explode, but the cost of motion for a batch of work is drastically higher than the cost of motion for a single change, and it increases superlinearly. Imagine dragging a slider across a bar, with “valuable work” on the left and “rework and remediation” on the right. Batch size moves the slider right in increasingly broad bumps.

Small batches have many technical benefits, and they also help the organization respond to changing conditions and new knowledge by providing many opportunities to redirect their investment. You might reach a goal with fewer changes than anticipated, allowing you to stop early and move to a new goal. Or, you may realize the current approach won’t work, allowing you to try a different approach before you’ve run out of budget.

Most crucially, small batches let you get feedback sooner. This feedback ensures your investment and effort are having the intended impact. And this is the part many organizations fail to connect — at significant cost to their goals.

In the rush to deliver work quickly, organizations aren’t listening for feedback. For many years, intelligent people have been saying you have to go slow to go fast. If you have no time to close feedback loops as you speed through the list of features to deliver, it’s time to discover that “faster is slower,” as Peter Senge, system scientist and author of The Fifth Discipline, put it.

User-Centrism Is Crucial

The DORA research program has also found this concept of slowing down to move faster. The State of DevOps Report introduced the concept of user-centric teams in 2023, and the findings were validated once more in 2024.

The superpower of user-centric teams is that they can achieve the highest levels of product performance with lower throughput. High-throughput teams may be able to deliver far more frequently, but without that crucial feedback, they create low-value features.

Successful features aren’t just those delivered on time and on budget — or incredibly fast. They are features that delight users by improving their ability to achieve their tasks. When you can deliver a high ratio of successful features, you don’t need to depend on the change volume required by hit-and-miss organizations.

Go Ahead! Deploy on Friday!

Mon, 11 Aug 2025 13:12:30 +0000

Improving your deployment pipeline reduces the risk of failed deployments overall rather than choosing which day will be a bad day.

Avoiding Friday deployments is driven by a goal that, while admirable, is better achieved in other ways. Yet, organizations are more likely to deploy on Friday than on a Monday, which shows the industry doesn’t buy the myth that you shouldn’t deploy on Friday.

Few Practices Are Truly Best Practices

While you used to hear about best practices all the time, you’ll have noticed that industry experts have become increasingly cautious about the term. Best practices do exist, such as using version control instead of a network share to store your source code. Many other practices turn out to be simply good, rather than best.

The idea of best practices is that they are table stakes for software delivery, and working without them can be harmful. Good practices, on the other hand, are options. You don’t have to adopt every good practice, as you can cover risk areas with a carefully selected option from the menu of all tried-and-tested ways to solve a problem.

If your end users are reporting escaped bugs, you can apply one or more testing and monitoring good practices to catch similar issues before users experience them. You look at different testing and monitoring approaches and try one to see its effectiveness. The problem could be solved after you adopt one practice, or it might take several complementary approaches to improve the situation.

Crucially, you should stop adding practices once you’ve solved the problem. Adding further practices that aren’t required results in unnecessary complexity, which can be harmful to software delivery.

Finally, there are practices that are actively harmful when pursued. These are often well-intentioned and almost always presented as best practices, but empirical evidence and rigorous research have proven them to be false. Examples of these harmful practices include Gitflow, working in large batches, and heavyweight change-approval processes.

A good heuristic for spotting an anti-pattern is that you’ve being told something is a best practice, but it doesn’t sound like table-stakes basic software delivery. If there’s any doubt, look for trusted advice from someone with plenty of experience and cross-reference dependable research, such as the Accelerate State of DevOps Report.

Never Deploy on a Friday

With the practices primer firmly in mind, let’s consider whether we should deploy on Friday. After the recent CrowdStrike outage, many people suggested things could have been improved if they hadn’t deployed on Friday.

It’s hard to understand how deploying on Thursday would have improved the CrowdStrike issue. Do we not fly planes or use computers on Thursday? We can explore this confusing claim by looking at the perceived benefits of banning Friday deployments.

Why You Should Avoid Friday Deployments

I asked folks why we should avoid Friday deployments to see if there was some merit to the claims. As someone whose mind was changed on tabs vs. spaces by solid arguments, I believed I could be convinced given a compelling argument.

The most common argument for a Friday moratorium was that it would allow developers to spend the weekend with their families instead of working to restore services.

This is only true if your time to recover from a failed deployment is almost exactly a day. If it takes more than a day, you’ll be working on Saturday to recover from your Thursday deployment, unless you also stop deployments on Thursday. If you can recover in less than a day, you could deploy on Friday and still get to the beach on Saturday.

The longer your recovery times, the further in the past you need to deploy to avoid working on the weekend. For example, if it takes you a week to recover from a failed deployment, you need to deploy last Friday to avoid working this weekend, though this does mean you have to work last weekend.

The reality is that recovery times aren’t constant. Some problems are easier to recover from than others. Having a distribution of recovery times means you are taking a probabilistic approach to protecting the weekend. If you deploy every day, you’ll discover that Friday deployments have a higher probability of disrupting the weekend than Monday deployments.

When you take this approach, you’ll find there are plenty of improvements you can make to your deployment pipeline that reduce the probability of disruption. Banning deployments doesn’t reduce your overall change failure rate, it just means your Monday deployments will fail more often. Improving your deployment pipeline reduces the risk of failed deployments overall, which is far more positive than simply choosing which day will be a bad day.

Work-life balance applies to Monday night just as much as it applies to the weekend. People have personal commitments every day of the week, from school runs to birthdays and anniversaries to arrangements made to meet an old friend. Each of these is important, so making improvements that reduce failed deployments protects work-life balance more than shifting them to a different workday.

Real Reasons To Plan Deployments

There are reasons to avoid deploying at specific times, but they are related to your industry. For example, in the retail industry, you avoid updating the software on tills when the store is open. You don’t need a new version of software while you’re checking out a customer and have a queue of shoppers waiting.

Your release plan would set out the times to deploy and the times to avoid. It would also capture the process for training retail store staff so they know what’s changed before they raise the shutters.

By thinking of the people affected by our software, we consider many more people than if we just think of ourselves. If we think of all the people depending on our software, we can consider the work-life balance of a thousand times more people. Ideally, we’d never have a failed deployment, and our rollout would have no downtime. In reality, things do sometimes go wrong, and having a strong recovery time can minimize the impact.

The research suggests there are capabilities that let you deploy more often while also reducing the failure rate. The top performers are deploying many times a day, including Fridays.

Deploying on Friday Is Commonplace

To understand whether the Friday deployment ban was affecting real organizations, I analyzed over 32 million deployments to see when they were taking place. The data cuts across all organization sizes and many industries. It turns out that deploying on Friday is more common than deploying on Monday.

This is great news, as it demonstrates that the myth of avoiding Fridays has little traction in practice.

Decide for Yourself but Don’t Propagate the Myth

It’s perfectly acceptable for your organization to decide they don’t want to deploy on Fridays, though some curiosity about why will either turn up interesting domain knowledge or highlight some things you can improve in your deployment pipeline. What’s less appealing is broadcasting “don’t deploy on Fridays” as a best practice.

Working in small batches is known to improve software delivery performance. If you are following continuous delivery and DevOps, you might be deploying five times a day. If you rule out Fridays, you build up a Monday deployment that’s five times bigger than your normal batch size. You are opting to downgrade your performance from “on demand” to “daily.”

The more continuously you deploy, the worse the idea of stopping for a day becomes. That means that the members the “don’t deploy on Friday” movement, in the absence of specific organizational context, are opting for mediocrity.

Don’t just start deploying on Fridays. Take this as an opportunity to assess your situation, understand users and customers, and start improving your software delivery capabilities.

From Vanilla Template to Still.js Components: A Full Build and Deployment Guide

Mon, 11 Aug 2025 02:56:47 +0000

A full Still.js build from raw HTML to deployment — with zero dependencies.

A few days ago, I was asked about migrating a project to Still.js, this article is accompanied by a video demonstrating it.

Because it’s built in Vanilla JavaScript, Still.js combines perfectly with a template that is based with pure/raw HTML, CSS and JavaScript, even if some library (e.g. jQuery, Bootstrap) was used, Still.js helps you to ease separate things into components, as show cased in this video.

What will be covered:

Migrating a Vanilla web template to Still.js
Back down the template into components conveniently
Load template’s JavaScript code properly according to Still.js architecture
Deploy to the cloud

Key Considerations:

When using templates with a lot animations, or that depends on different javaScript library to load, it’s important to deeply understand it (the template) so to orchestrate each
Script dependency just the same way it happens with raw HTML, CSS and JavaScript.

Minimalist third party Script dependency approach:

Now a days a lot of features like animation and more (e.g. parallax, singlePageNav, dialog, IntersectionObserver - Lazy animation) are browser native, hence, this would impact a lot in the choosing on what/when to use libraries especially when it comes to animation which some web pages are depending a lot.

Vanilla JavaScript is one of the core philosophy of Still.js, hence you can use everything as natural as possible from Web Semantic to straight DOM manipulation.

We’ll use this template, and we’ll be deploying our page to Render which will provide us with a custom domain.

In summary, on the coding and structure side of things the steps will be as follow:

the HTML code will be moved to the Still.js template/template file (.html)
Run template JavaScript animation in the stAfterInit hook, ensuring it executes after component load
Convert sections into autonomous components

Conclusion

Still.js helps turn vanilla templates into fast, modular, and lightweight sites with zero dependencies, giving you full control using pure JavaScript. Proper code organization is key to avoid issues like bloating or conflicts, and a vanilla-first approach is recommended, external libraries should only be used when necessary.

What’s Next?

Don't forget to follow the hands-on video till the end so we can make the deploy.

Expand Your Still.js Skills

Explore advanced Still.js features like state management, routing, or
integrating APIs.
Try building a small SPA or dashboard using
Still.js components capabilities.

Contribute to Still.js

Still.js is open-source, consider contributing or helping improve documentation.
Join the discord channel to get fast updates and follow the discussions

Ask more if needed

Share any topic you want to see cover so content (e.g. video, article) can be produced.

Se ya in the next one

Gatekeepers Limit Continuous Delivery’s Benefits

Thu, 24 Jul 2025 19:52:13 +0000

Having too few people with deployment authority reduces software delivery performance.

Developer experience and burnout may have put platform engineering in the spotlight, but focusing on continuous delivery will likely improve developer experience (DevEx) the most at your organization.

There is, however, a speed bump ahead for those automating their deployment pipeline: deployment gatekeepers.

If you don’t increase the number of people with deployment authority, you’ll miss many of the benefits of continuous delivery. A single deployment gatekeeper will lower your chances of getting a return on your investment within the first 100 days and permanently limit your software delivery performance.

So, how does this happen?

Failing To Respond to Change

There is a dramatic shift in your work system once you automate your deployment pipeline. You’ll have saved many hours of manual work and made the deployment process more reliable. These benefits are often so dramatic you might stop looking for further gains.

Accepting a faster version of your current deployment process means failing to respond to change. This holds back your software delivery performance and reduces the impact of your software on its users and your organization.

In the Octopus Deployment Survey, we found that teams with a single deployment gatekeeper were less likely to see efficiency gains within the first 100 days than teams with more than one deployer.

CD tools bring granular role-based access controls, so deployers don’t need privileged infrastructure access. Your automation captures the process, so your CD tool will deploy the same way every time. Your IT service management tools can capture and streamline change approvals. Deployments are more repeatable and reliable. Pressing “go” on an automated deployment should be low risk and low ceremony. It might not even be a technical task any longer.

There are two hidden costs when you fail to use your tool’s deployment-specific features. It delays return on investment and stops automation from delivering its full promise. With more than one deployer, 96% of organizations obtained efficiency improvements in the first 100 days, compared to 83% of organizations with deployment gatekeepers.

You must acknowledge that continuous delivery and automated deployment pipelines change the nature of software delivery. Don’t be satisfied with the reliability improvements. Look outside your organization for inspiration and you’ll find industry peers who have sped up their software delivery.

Fully embracing modern software delivery benefits teams, users and organizations.

Gatekeeping’s Impact on Software Delivery Performance

Since the survey, we’ve further tested our findings on gatekeepers. We looked at how the number of deployers related to the throughput metrics from the Accelerate State of DevOps Reports.

Deployment frequency: How often your organization deploys code to production
Lead time for changes: The time it takes for code changes to make it into production

Teams with four or more deployers achieved the highest performance level for throughput. They had shorter lead times for changes, and deployed more often. In terms of the other two groups, there was an interesting result: Gatekeepers deploy more often than teams with two to three deployers, but their lead times are longer.

The chart shows the difference in performance, with the sweet spot being the top left.

One explanation for gatekeeping is that deployments are only partially automated.

Teams without fully automated deployment pipelines will likely require gatekeepers, as they must perform tasks that require privileged access. They might manually update traffic on a load balancer or run a script to perform a post-deployment task such as cache clearance.

Finding a way to automate these final tasks would make it possible to safely increase the number of deployers. Training additional deployers is a crucial improvement opportunity in the free and anonymous Octopus Deployment Capability Assessment, which you can use as part of your continuous improvement process.

One of Many Factors

You need many skills for high-performance software delivery, but gatekeeping will likely limit most other improvement attempts. If you have to wait on one person or a small group of authorized deployers, you’ll have a limit on how much you can improve your deployment frequency and change lead times.

Gatekeepers are the constraint, so optimizing other parts of your software delivery won’t make a difference. Add more deployers and see how it transforms your performance.

Mastering Deployment: Top Tools You Must Know Before Launching Your App or Model!

Sat, 05 Jul 2025 19:31:21 +0000

Mastering Deployment: Top Tools You Must Know Before Launching Your App or Model!

In the fast-paced world of development, building an application or AI model is only half the journey—the real magic happens when you deploy it! Whether you’re launching a web app, microservice, or a machine learning model, choosing the right deployment tool is crucial for efficiency, scalability, and cost savings.

Let’s explore the top deployment tools, their unique features, real-world use cases, costs, and best-fit scenarios!

1️⃣ Docker — Containerization King

"Build once, run anywhere."

Features:

Packages your app and its environment into a lightweight container.
Ensures consistency across development → staging → production.
Great for microservices architecture.
Easy to scale and move across platforms (cloud, on-premise, etc.).

✅ Best For:

Web applications, APIs, microservices.
Environments with different system dependencies.

Cost:

Free for individuals.
Docker Pro: \~\$5/month, Business plans for teams.

Example:

Deploy a Flask ML model wrapped in a Docker container for seamless CI/CD integration.

2️⃣ Kubernetes (K8s) ☸️ — The Orchestrator

“Manage thousands of containers like a breeze.”

Features:

Automates deployment, scaling, and management of containerized apps.
Self-healing, load balancing, auto-rollouts/rollbacks.
Highly configurable and cloud-agnostic.

✅ Best For:

Large-scale production systems, ML model clusters, SaaS products.

Cost:

Open-source, but infra and managed K8s services (GKE, EKS, AKS) add cost.

Example:

Running a high-load AI recommendation system deployed via Kubernetes on Google Cloud (GKE).

3️⃣ Heroku — Developer's Delight

“Focus on code, not servers.”

Features:

PaaS (Platform as a Service), simple Git-based deployments.
Supports many languages: Ruby, Python, Node.js, Java.
Add-ons for databases, caching, logs, etc.

✅ Best For:

Startups, MVPs, and personal projects.

Cost:

Free tier available, paid plans from \~\$7/month/app.

Example:

Deploy your first Rails or Django app with a single command:

git push heroku main

4️⃣ AWS EC2 + CodeDeploy — Infrastructure Powerhouse

“Build custom deployments with full control.”

Features:

Launch virtual machines (EC2) with your custom app.
Use AWS CodeDeploy for seamless rollouts and CI/CD.
Highly scalable, integrates with S3, Lambda, CloudWatch.

✅ Best For:

Enterprise-grade apps needing custom configurations.
Backend-heavy workloads, ML inference models.

Cost:

Pay-as-you-go model. Free tier available for EC2 (750 hrs/month for 12 months).

⚙️ Example:

Deploy a deep learning model on an EC2 GPU instance with auto-scaling using CodeDeploy.

5️⃣ Vercel & Netlify — JAMStack Heroes

“Frontend first? These are your weapons.”

Features:

Zero-config deployment for React, Vue, Svelte, static sites.
Global CDN, Git integration, rollbacks, preview URLs.
Functions-as-a-service for backend logic.

✅ Best For:

Frontend apps, static sites, blogs, portfolios.

Cost:

Free tiers; Pro plans \~\$20/month.

Example:

Deploy a Next.js blog with serverless APIs using Vercel in under 1 minute.

6️⃣ Hugging Face Spaces — ML Model Showcase

“Deploy your ML models with a beautiful UI — instantly.”

Features:

Direct integration with Gradio or Streamlit UIs.
Deploy PyTorch, TensorFlow, or Transformers-based models.
Community sharing + version control.

✅ Best For:

ML model demos, prototyping, academic projects.

Cost:

Free public Spaces; Pro starts from \~\$9/month.

Example:

Deploy a sentiment analysis model using Gradio on a Hugging Face Space.

7️⃣ Render — Modern Cloud Alternative

“All-in-one cloud platform with simple pricing.”

Features:

Supports Docker, static sites, APIs, background workers.
Auto HTTPS, pull-based deployments.
PostgreSQL, Redis support.

✅ Best For:

MVPs, SaaS, side projects.

Cost:

Generous free tier; paid plans from \~\$7/month.

⚡ Example:

Deploy a background job worker for your Ruby on Rails app without DevOps headaches.

8️⃣ Google Cloud Run ☁️ — Serverless Magic

“Scale from zero to millions — serverlessly.”

Features:

Deploy containers that scale automatically with request volume.
Pay-per-use pricing model.
Integrated with Google Cloud services.

✅ Best For:

Containerized webhooks, APIs, ML models with variable load.

Cost:

Free tier includes 2 million requests/month. Pay-per-second billing after.

Example:

Deploy a text summarization ML model container via Cloud Run and trigger with HTTP requests.

Choosing the Right Deployment Tool

Tool	Best For	Cost Efficiency	Scalability
Docker	Microservices, ML Dev	✅ High	✅ With orchestration
Kubernetes	Enterprise workloads	⚠️ Moderate (infra)	✅✅✅
Heroku	MVPs, Startups	✅ Beginner-friendly	⚠️ Limited
AWS EC2 + CodeDeploy	Full control & heavy compute	⚠️ Variable	✅✅
Vercel/Netlify	Frontend apps	✅ Extremely efficient	✅
Hugging Face Spaces	ML model demos	✅ For public Spaces	⚠️ Limited compute
Render	Modern full-stack apps	✅ Efficient	✅
Google Cloud Run	Dynamic workloads	✅ Serverless economy	✅✅✅

Final Thoughts: Launch Like a Pro!

Your product is only as impactful as its deployment experience. Choose tools that:

Match your app architecture
Suit your budget
Support team collaboration
Enable future scaling

Whether you’re a solo developer building the next big SaaS, or a data scientist sharing your ML model with the world — choose wisely, deploy smartly.

Have a favorite tool or story to share? Drop it in the comments or tag me! *

Let’s make deployment simple, smart, and successful. ✨

How Kubernetes Simplifies Cloud Application Deployment, Scaling, and Management

Fri, 14 Mar 2025 04:29:22 +0000

As cloud-native applications continue to gain momentum, the need for efficient, scalable, and automated management of containers becomes more essential. Kubernetes has emerged as the industry-standard platform for automating the deployment, scaling, and management of containerized applications across various cloud environments. This article dives deep into how Kubernetes transforms the way organizations handle their cloud application lifecycle, providing advanced features such as auto-scaling, self-healing, and high availability.

What is Kubernetes?

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform designed to automate the deployment, scaling, and management of containerized applications. Originally developed by Google, Kubernetes has become the go-to solution for organizations looking to streamline their cloud infrastructure management. By abstracting away the complexity of infrastructure management, Kubernetes allows developers to focus on application code while leaving operational concerns to the platform.

In a modern cloud environment, Kubernetes enables seamless container management across on-premises data centers, public clouds, and hybrid environments. This abstraction makes it possible to run applications in a consistent manner, regardless of the underlying hardware or cloud provider.

Automating Application Deployment with Kubernetes

One of the most powerful features of Kubernetes is its ability to automate the deployment of applications. Traditionally, deploying an application to a cloud environment involves manually provisioning servers, configuring networking, and installing dependencies. Kubernetes eliminates much of this manual effort by using containers as the foundation for deploying applications. Containers encapsulate an application and its dependencies, ensuring that the application runs consistently across various environments, from local development to production in the cloud.

In Kubernetes, deployments are defined using declarative configuration files, typically written in YAML or JSON. These configuration files describe the desired state of the application, including the number of replicas, storage requirements, and networking policies. Kubernetes then works to ensure that the application is deployed according to the defined specifications, automatically handling the provisioning of resources and setting up the necessary services to make the application accessible to users.

The declarative nature of Kubernetes means that developers can version control their application’s infrastructure. If an update is made to the configuration, Kubernetes automatically adjusts the system to match the desired state, whether that’s adding more replicas or rolling back to a previous version. This results in faster, more reliable deployments.

Scaling Applications Automatically with Kubernetes

Scaling is one of the key challenges faced when managing cloud applications, especially as the number of users fluctuates. Kubernetes excels in automatic scaling, providing both horizontal and vertical scaling mechanisms for applications. Horizontal scaling is the process of increasing or decreasing the number of application instances (pods) to match the demand. Kubernetes can scale your application based on a variety of metrics, such as CPU usage, memory usage, or custom metrics that you define.

The Kubernetes Horizontal Pod Autoscaler (HPA) is a built-in feature that automatically adjusts the number of pods running in a deployment based on real-time metrics. For example, if the CPU usage of a pod exceeds a threshold, the HPA can spin up additional replicas to distribute the load. Conversely, when demand decreases, Kubernetes will scale down the number of replicas to save resources. This elasticity ensures that resources are used efficiently, while maintaining optimal performance under varying traffic loads.

In addition to HPA, Kubernetes also supports **Cluster Autoscaling**. This feature allows Kubernetes to automatically scale the underlying infrastructure by adding or removing nodes (virtual machines) in response to resource demands. This is particularly useful when running workloads in a cloud environment, where infrastructure scaling can be automated based on predefined policies. Kubernetes can add more nodes when there are too many pending pods or remove nodes when there is excess capacity.

Self-Healing and Fault Tolerance in Kubernetes

Cloud applications need to be highly available and resilient to failures. Kubernetes helps ensure that applications are self-healing and fault-tolerant by continuously monitoring the health of deployed services. When an application or service experiences an issue, Kubernetes automatically takes corrective action to restore the desired state.

For example, if a pod crashes due to an error or becomes unresponsive, Kubernetes will automatically restart it or replace it with a new pod. This process is transparent to users, who experience minimal disruptions. Additionally, Kubernetes supports the concept of “replicas” where multiple instances of an application are run simultaneously across different nodes, ensuring that the application remains available even if one of the instances fails.

Kubernetes also performs regular health checks using readiness and liveness probes. A readiness probe checks if a container is ready to accept traffic, while a liveness probe checks if the container is still running. If a liveness probe fails, Kubernetes will automatically restart the container, ensuring that unhealthy services are quickly replaced with healthy ones.

Service Discovery and Load Balancing in Kubernetes

In modern cloud applications, services often need to communicate with one another. Kubernetes simplifies service discovery by providing an internal DNS-based service discovery system. Every service within a Kubernetes cluster is automatically assigned a DNS name, allowing other services to connect to it by using its service name, rather than hardcoding IP addresses. This dynamic service discovery makes it easy to update or replace services without disrupting the entire application.

Kubernetes also provides built-in load balancing. When users or other services send traffic to an application, Kubernetes automatically distributes that traffic across all the healthy instances (pods) of the service, ensuring that no single instance is overloaded. This load balancing mechanism helps achieve high availability and ensures that resources are used effectively, providing a smooth user experience even under heavy traffic conditions.

Configuring and Managing Cloud Environments with Kubernetes

Managing different environments in the cloud can be a complex task, especially as the number of services and applications grows. Kubernetes simplifies this by using namespaces, which allow you to isolate resources within a cluster. This makes it easy to manage multiple environments, such as development, staging, and production, all within a single cluster. Each environment can have its own set of resources, configurations, and access controls, while still sharing the underlying infrastructure.

Additionally, Kubernetes provides the ability to manage configuration data and sensitive information using ConfigMaps and Secrets. ConfigMaps store non-sensitive configuration data, such as environment variables or configuration files, while Secrets store sensitive data, such as passwords or API keys. These resources can be injected into applications at runtime, making it easier to manage environment-specific configurations without having to modify application code.

Integrating Kubernetes with CI/CD Pipelines

Continuous integration and continuous deployment (CI/CD) practices are critical for modern software development. Kubernetes integrates seamlessly with CI/CD pipelines, enabling automated deployment of containerized applications as new code is pushed to version control systems.

By integrating Kubernetes with CI/CD tools like Jenkins, GitLab CI, or CircleCI, developers can create automated workflows that deploy new versions of an application to the Kubernetes cluster whenever new changes are made. This enables faster feedback loops, improved code quality, and more frequent releases. Kubernetes helps automate the entire process, from building containers to deploying them to production, ensuring consistency and reliability in application delivery.

Conclusion

Kubernetes is a powerful tool for automating the deployment, scaling, and management of containerized applications in the cloud. By leveraging its robust features, such as self-healing, auto-scaling, service discovery, and CI/CD integration, organizations can achieve greater efficiency, reliability, and flexibility in their cloud environments. Kubernetes empowers developers to focus on building applications while leaving the complexities of infrastructure management to the platform.

Whether you're deploying simple microservices or large-scale cloud applications, Kubernetes helps ensure that your applications are always available, scalable, and resilient, providing a smooth and reliable experience for both developers and users alike.

Exploring Ansible Adhoc Commands For Beginners

Sat, 15 Feb 2025 08:16:00 +0000

Ansible is a powerful automation tool that simplifies IT tasks such as configuration management, application deployment, and task automation. One of its essential features is the ability to run ad hoc commands. In this blog post, we'll delve into Ansible ad hoc commands, their syntax, and various use cases.

What Are Ansible Adhoc Commands?

Ansible ad hoc commands are single-line commands used to perform quick tasks without writing a full Ansible playbook. They are convenient for executing simple operations on remote hosts immediately. This makes them ideal for tasks like checking system information, managing files, and installing packages.

Syntax of Ansible Adhoc Commands

The basic syntax of an Ansible ad hoc command is as follows:

ansible [host-pattern] -m [module] -a "[module options]"

where,

ansible: The command to run Ansible.

[host-pattern]: Specifies the target hosts or groups of hosts.

-m [module]: Specifies the Ansible module to use.

-a "[module options]": Specifies the arguments or options for the module.

Example:
To ping all hosts in the inventory:

ansible all -m ping

Common Use Cases of Ansible Adhoc Commands

Checking Connectivity

To check the connectivity between the Ansible control node and the remote hosts, you can use the ping module:

ansible all -m ping

This command will return a "pong" response from each reachable host.

Gathering System Information

The setup module can be used to gather detailed system information from the remote hosts:

ansible all -m setup

This command returns a JSON output containing various facts about the target systems.

Managing Files

To create a directory on remote hosts using the file module:

ansible all -m file -a "path=/tmp/test_dir state=directory"

This command creates a directory named test_dir in the /tmp directory on all hosts.

Installing Packages

The yum module (for RHEL-based systems) can be used to install packages:

ansible all -m yum -a "name=httpd state=present"

This command installs the httpd package on all hosts.

Running Commands

To execute a shell command on remote hosts, you can use the command module:

ansible all -m command -a "uname -a"
ansible all -m shell -a "uname -a"

This command retrieves the kernel version and system information from all hosts.

Copying Files

To copy a file from the Ansible control node to the remote hosts, you can use the copy module:

ansible all -m copy -a "src=/path/to/source dest=/path/to/destination"

This command copies the specified file to the target destination on all hosts.

Fetch Files

To transfer files from the remote hosts to the Ansible control node, you can use fetch module:

ansible all -m fetch -a "src=/path/to/source dest=/path/to/destination flat=yes"

This command will get files from remote machine to local machine.

Tip: Use Ansible ad hoc commands for quick, one-time tasks instead of writing full playbooks. This is especially useful for troubleshooting, system checks, and immediate configuration changes.

Caution: Be cautious when running ad hoc commands on multiple hosts, as changes take effect immediately without confirmation. Always test commands on a single host or in a controlled environment before executing them on a large scale.

Note: While ad hoc commands are powerful, they do not maintain state. For long-term configuration management, use Ansible playbooks to ensure consistency across your infrastructure.

Conclusion

Ansible ad hoc commands are a powerful tool for performing quick, on-the-fly tasks. Their simplicity and flexibility make them an essential part of any Ansible user's toolkit. Whether you're checking connectivity, gathering system information, managing files, or installing packages, ad hoc commands provide a straightforward way to get the job done. Start experimenting with them today to see how they can streamline your IT operations!

Ansible in Automation, Configuration management and Devops

Mon, 03 Feb 2025 08:42:07 +0000

What is Ansible?

In the fast-paced world of software development, automation and efficient workflows are key to success. Enter Ansible, an open-source tool that has transformed the way we approach automation, configuration management, continuous deployment, and overall DevOps practices.

Ansible is an IT automation tool that allows you to manage systems, deploy software, and orchestrate more advanced IT tasks. Its simplicity and powerful features have made it a favorite among developers and operations teams.

How Ansible Works

Unlike other automation tools that require agents to be installed on managed systems, Ansible is agentless. It connects to remote machines using SSH (Secure Shell) and executes tasks using predefined modules. These tasks are written in YAML-based playbooks, making it easy to define and manage automation workflows.

Ansible operates from a control node, which sends commands to managed nodes, ensuring that configurations and deployments are consistent across all systems.

The Benefits of Ansible

- Simple Automation: Ansible uses a straightforward YAML syntax, making
it easy to write automation scripts, also known as playbooks. This
simplicity reduces the learning curve and allows teams to get started
quickly.

- Efficient Configuration Management With Ansible: You can ensure that
your systems are configured consistently. By defining the desired
state of your infrastructure in playbooks, Ansible automatically
adjusts any discrepancies, maintaining a uniform environment.

- Continuous Deployment: Ansible streamlines the deployment process,
allowing you to automate the entire lifecycle of your
applications.From code integration to testing and deployment, Ansible
ensures that updates are delivered smoothly and reliably.

- Enhanced DevOps Practices: Ansible fosters collaboration between
development and operations teams. By using a single tool for both
automation and configuration management, it bridges the gap and
improves communication, leading to faster and more efficient
workflows.

Real-World Applications

- Infrastructure as Code (IaC): Ansible allows you to define and manage your infrastructure as code. This means you can version-control your infrastructure alongside your application code, making it easier to reproduce and manage environments.

- Application Deployment: Deploying applications manually can be time-consuming and error-prone. Ansible automates the deployment process, ensuring that every deployment is consistent and reducing the risk of human error.

- Configuration Management: Maintaining consistent configurations across multiple servers is challenging. Ansible simplifies this by allowing you to define configurations once and apply them across all your systems.

- Continuous Integration and Continuous Deployment (CI/CD): Ansible integrates seamlessly with CI/CD pipelines, automating the build, test, and deployment processes. This ensures that new features and bug fixes are delivered to users quickly and reliably.

Getting Started with Ansible

To install Ansible on a Linux system, use the following command:

sudo apt update && sudo apt install ansible -y

For Red Hat-based systems:

sudo yum install ansible -y

Writing Your First Ansible Playbook

Here's an example of a simple Ansible playbook that installs Apache on a remote server:

- name: Install Apache Server
  hosts: web_servers
  become: yes
  tasks:
    - name: Install Apache
      apt:
        name: apache2
        state: present

Run the playbook using:

ansible-playbook apache.yml

Tip: If you’re managing multiple environments (e.g., development, staging, production), consider using Ansible Vault to encrypt sensitive information like API keys, database passwords, and SSH credentials within your playbooks.

Caution: Be cautious when running Ansible as root (using become: yes). If a playbook contains misconfigured tasks, it may cause unintended changes or even break critical system components. Always test your playbooks in a staging environment before deploying them in production.

Note: Ansible follows an idempotent approach, meaning that running the same playbook multiple times will not cause unnecessary changes. It only applies modifications if the system state differs from the defined configuration.

Conclusion

Ansible has revolutionized the way we approach automation, configuration management, continuous deployment, and DevOps practices. Its simplicity, efficiency, and power make it an invaluable tool for any development and operations team. By adopting Ansible, you can streamline your workflows, improve collaboration, and deliver software more efficiently.

ContainerCraft: A Deep Dive into Node.js Containerization

Thu, 30 Jan 2025 09:58:52 +0000

Master the art of containerizing Node.js applications with Docker through practical implementation of DevOps best practices, security measures, and production-ready configurations. From development to deployment, mastering the art of containerizing Node.js applications with Docker.

Introduction

In today's cloud-native world, containerization has become an essential skill for developers and DevOps engineers alike. Through my journey with ContainerCraft, a project focused on mastering Node.js containerization, I've gained valuable insights into creating efficient, secure, and production-ready containerized applications. In this article, I'll share the key learnings and best practices that emerged from this experience.

The Architecture: Simplicity Meets Efficiency

ContainerCraft implements a straightforward yet powerful architecture. At its core lies a Node.js HTTP server, carefully containerized using Docker. The application runs on a lightweight Alpine Linux-based image, demonstrating how to balance functionality with resource efficiency.

The architecture focuses on three key components:

lightweight Node.js HTTP server
Docker container configuration optimized for production
Streamlined deployment workflow

Key Technical Decisions

Base Image Selection

Choosing node:14-alpine as our base image wasn't just about size – it was about security, stability, and maintainability. Alpine Linux provides a minimal attack surface while ensuring all essential functionalities are preserved.

Port Configuration

The internal container port (8080) is mapped to port 80 on the host system, following the principle of separation of concerns. This configuration allows for flexibility in deployment while maintaining consistent internal application behavior.

Security Implementation

Security wasn't an afterthought – it was built into the container from the ground up:

Implementation of CORS headers
Proper environment variable management
Minimal container privileges
Regular security scanning integration

DevOps Best Practices

Through ContainerCraft, several DevOps best practices emerged as crucial for success:

1. Image Optimization

Implementing multi-stage builds
Utilizing Docker layer caching effectively
Minimizing image size through careful dependency management

2. Production Readiness

Robust health check implementation
Proper resource constraint configuration
Comprehensive logging setup
Environment-specific configurations

3. Monitoring and Maintenance

Container health monitoring
Resource usage tracking
Log management strategies
Backup and restore procedures

Lessons Learned

The journey with ContainerCraft taught valuable lessons about containerization:

Simplicity is Key: A straightforward architecture often leads to more maintainable solutions.
Security First: Building security into the container from the start is easier than adding it later.
Resource Efficiency: Careful consideration of base images and dependencies can significantly impact performance.
Documentation Matters: Clear documentation and reference guides are crucial for team collaboration and maintenance.

Future Enhancements

Looking ahead, several exciting enhancements are planned:

Implementation of automated CI/CD pipelines
Integration of advanced monitoring systems
Kubernetes deployment configurations
Enhanced security scanning procedures
Automated testing framework integration

Conclusion

ContainerCraft represents more than just a containerized Node.js application – it's a practical demonstration of containerization best practices and DevOps principles. Through this project, we've seen how proper containerization can enhance application deployment, security, and maintainability.

The complete source code and documentation are available on GitHub, where you can explore the implementation details and contribute to the project.

Author: Md Toriqul Islam
Connect with me on LinkedIn or visit my portfolio for more DevOps insights.

Tags: Docker, Node.js, DevOps, Containerization, Software Engineering

Coder Legion - Recent posts tagged deployment

How to Fix an ARM64 WAF Deploy When Personal Edition Is Not Supported

Confirm the host before editing .env

The edition limit is not an image-tag typo

The screen that confirms the fix

After the console is up

Does Personal Edition run on an ARM64 SafeLine host?

Which environment lines are wrong on ARM if I keep the sample file?

What output confirms the corrected deploy?

Is arm64 outside the published architecture list?

What should I verify before the first docker compose up?

Why I Check ARM64 Edition Limits Before Turning SafeLine On

Confirm the edition before touching images

Prove the host meets the published minimum

Decide what on will change for clients

Choose the install path and the release channel

Turn the proxy on, then test, then cut over

Does Personal Edition work on ARM64?

What host checks should pass before installation?

What changes when protection is turned on?

How can I test blocking without inventing new attacks?

Does the LTS channel remove the ARM edition limit?

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?

Your App Works Locally. What Changes When It Goes to Production?

It Works on My Machine. What's the Problem?

Your App Needs a Home

The Frontend and Backend Need to Find Each Other

Where Does Your Data Live?

From Localhost to a Live Application

CloudPloy: Deploy anywhere from your AI

How to Write to Web.config in Medium Trust

🚀 Feature Flags - The Secret Behind Safe Deployments

🧠 What Are Feature Flags?

Key idea:

🎯 Why Feature Flags Matter

Without Feature Flags

With Feature Flags

Benefits of Feature Flags

🛒 Real-World Example

Without Feature Flags

With Feature Flags

🧩 Types of Feature Flags

1️⃣ Release Flags

2️⃣ Experiment Flags (A/B Testing)

3️⃣ Operational Flags

4️⃣ Permission Flags

⚙️ Feature Flags vs Configuration Flags

Feature Flags

Configuration Flags

🧪 Simple Implementation Example (Go)

🌐 Remote Feature Flag Systems

📈 Gradual Rollouts

🎯 Targeted Rollouts

🐤 Canary Releases

🌑 Dark Launching

⚠️ The Hidden Problem: Feature Flag Debt

🚨 Common Mistakes With Feature Flags

1️⃣ Flag Explosion

2️⃣ Flags in Performance-Critical Paths

3️⃣ Long-Lived Release Flags

4️⃣ Mixing Flags With Business Logic