DEV Community: Tesleem Amuda

The Docker Mistakes That Only Show Up After You Deploy

Tesleem Amuda — Thu, 27 Aug 2026 00:17:45 +0000

Most Docker tutorials stop at docker build and call it done. The real problems, the ones that actually cost you time, show up later. When you push to a registry. When CI tries to reproduce your laptop build. When the chip on your machine is not the chip on the server.

This is what broke while I was taking a FastAPI service from a working local Compose stack to something I would let CI ship. And why each fix works the way it does.

## Multi-stage builds are not optional once the image leaves your laptop

A single-stage Dockerfile that does pip install and COPY . . will build. It will also hand you a 400MB+ image for an API with three routes. Pip's cache, build tools, and the whole project directory end up inside a production artifact that never needed any of it.

The fix is structural, not clever. Build in one stage. Run in another. Copy across only the finished product.

My builder stage creates a virtualenv and installs dependencies into it. The runtime stage starts from a fresh copy of the same base image and copies exactly two things: that venv, and the application code. No compilers. No .git. No pip cache sitting in a layer you will pay to pull forever.

Final size: 170MB. The gap between that and a naive build is not a rounding error. It is the difference between an image your runners pull in two seconds and one that makes every pipeline feel slower than it should.

Do this every time as well: run as a non-root user inside the container.

RUN adduser --disabled-password --gecos '' appuser  
USER appuser

depends_on does not mean what people think it means

Compose depends_on waits for a container to start. It says nothing about whether that container can do any work yet.

Postgres is the usual trap. The container process is up in under a second. The database is not ready to accept connections for a few seconds after that. Your app starts, tries to connect immediately, fails, then either crash-loops or burns retries depending on how you wrote the client.

The fix is depends_on with condition: service_healthy, paired with a real healthcheck. For Postgres, pg_isready is the right check.

services:
  db:
    image: postgres:16-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 5s
      timeout: 5s
      retries: 10
  api:
    depends_on:
      db:
        condition: service_healthy

Now the API waits until Postgres can answer a query, not until PID 1 exists.

This bug almost never shows up in a demo. Demos are slow enough, by accident, that the race does not fire. It shows up in CI, under load, or at 2am. Fix it before it has a ticket number.

The architecture mismatch nobody puts in the quickstart

Build on Apple Silicon, deploy to a standard cloud VM, and you will hit this. Your image is arm64. The server is amd64. Docker will refuse to run it, or worse, emulate it badly enough that the container crash-loops and looks like an application bug.

The signature I keep seeing: container stuck in Restarting (255), logs that do not mention the app at all. The failure is under the process you think you are debugging.

Build both architectures and push a manifest list, not a single flat image:

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag ghcr.io/you/fastapi-service:latest \
  --push .

The registry then serves the variant that matches the host pulling it. One tag. Correct binary on every machine. You stop discovering architecture mismatches after the deploy already ran.

If you only need the server's architecture, still be explicit:

docker buildx build --platform linux/amd64 --push .

Implicit "whatever my laptop is" is how this class of bug is born.

CI that blocks, not CI that narrates

A pipeline that runs lint, test, and build, then paints green checkmarks, is only half the job. The other half is proving those checks can stop a merge.

Split the work into separate jobs and make build depend on test. That part is easy. The part worth verifying is the failure path. Break an assertion on purpose. Push it. Watch test go red and build get skipped because its dependency never passed.

Then turn on branch protection with required status checks. That is what turns a red X into a greyed-out merge button. A pipeline that reports failures without enforcing them is just a slower way to learn that something is broken.

If you have not watched a bad commit get blocked, you do not know whether the pipeline works. You only know that it runs.

The permission error that is not about your YAML

Deploying from GitHub Actions to GHCR, you will eventually hit:

denied: permission_denied: write_package

You already scoped the workflow token. packages: write is in the file. The job still dies.

The cause is easy to miss. If the package was first pushed from a laptop with a personal token, the package does not automatically trust the repo's GITHUB_TOKEN. The workflow can ask for write. The package can still say no.

The fix is in the package settings, not in YAML. Open the package, go to Manage Actions access, link the repository, grant write. One-time change. A permissions: block cannot override it, because the restriction lives on the package, not in the workflow.

Same class of problem as the others. The error shows up in Actions. The lever is one screen over.

What actually matters

None of this is exotic. It is the gap between "I can write a Dockerfile" and "I can let a machine ship this."

Multi-stage builds are not a nice-to-have. They are how you stop shipping a workshop as a runtime.
Health checks are not paranoia. They are how you stop a startup race from becoming an outage.
Cross-platform builds are not an edge case if you develop on Apple Silicon and deploy to amd64, which is a normal setup now.
CI that cannot block a merge is monitoring, not control.
Registry permissions live on the package. The workflow file is not the whole story.

The pattern across all of it: the failure never shows up where you were looking. It shows up one layer down, after the part you tested already worked.

Swap `ghcr.io/you/fastapi-service` for your real image name before you publish.   ``

Your API Isn't Ready for the Internet Yet

Tesleem Amuda — Sat, 08 Aug 2026 21:13:07 +0000

Most people deploy their first API the same way: expose it on 0.0.0.0 and hope for the best.
That's a mistake.
A production-ready API should never face the internet directly. Here's how to set it up properly, and why each layer exists.

Keep the API private by design

When your application starts, the bind address is a security decision.

0.0.0.0 means "accept connections from anywhere." Anyone who discovers the port can talk straight to your process.
127.0.0.1 means "accept connections only from this machine." Nothing outside the server can reach it. Always bind to 127.0.0.1. Your application was never meant to be the public face of the service. Something else should handle that job.

Put a reverse proxy in front

A reverse proxy sits between the internet and your application. Every request arrives at the proxy first. The proxy decides what to do, then forwards the request only when appropriate.
With Nginx the flow is simple:

Browser → Nginx (HTTPS, port 443) → Your API (HTTP, 127.0.0.1:3000)

Nginx is the only process the outside world ever touches. Your API works behind a locked door. Nginx holds the only key.
This separation delivers several practical benefits:
Nginx terminates TLS. Your application speaks plain HTTP and never needs to know about certificates. Encryption lives in one place instead of being duplicated across every service.
Nginx can log, rate-limit, and route without changing your code. Adding another service later is just another location block.
If the application crashes, the failure stays private. A raw stack trace never reaches the browser. Nginx can return a controlled response instead.
A minimal location block looks like this:

location /api/ {
 proxy_pass http://127.0.0.1:3000/;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
}

The proxy_pass line does the forwarding. The header lines are essential. Without them, every request appears to come from Nginx itself and your application loses the real client information.
Verify both directions. Confirm the API responds correctly through the public domain. Then confirm it does not respond when you hit the server IP directly on the application port. A working reverse proxy is not only "the front door works." It is also "there is no back door."
Let systemd keep the process alive
Starting an application in a terminal is fine for development. It is not acceptable in production. Close the session and the process dies.
systemd exists to start, stop, and supervise long-running services. A minimal service file looks like this:

[Service]
User=deploy
WorkingDirectory=/home/deploy/projects/api
ExecStart=/home/deploy/projects/api/venv/bin/uvicorn main:app - host 127.0.0.1 - port 3000
Restart=always
RestartSec=5

Restart=always combined with RestartSec=5 is the key.
In plain English: if the process ever stops for any reason, wait five seconds and start it again. No human intervention required.
Test it the hard way. Send a kill -9 to the process. Within seconds a new process appears with a fresh PID. Reboot the server. When the machine comes back, the service is already running because it was enabled on boot.
That is the real value of Restart=always. The system recovers while you are offline.

Make the deployment idempotent

The final piece is a single script that installs dependencies, deploys the code, configures systemd, and configures Nginx. The script must be safe to run more than once.
Run it on a fresh server and it builds everything from scratch. Run it again on the same server and nothing breaks or duplicates. That property is called idempotency.
A deploy script you cannot safely re-run is a script you will eventually be afraid to use. Design for the second run from the beginning.

Practical rules that hold up

Bind the application to 127.0.0.1. Let Nginx be the only process the internet can reach. Hand the responsibility of staying alive to systemd. Write every deployment step so it can be repeated safely.
These are not advanced techniques. They are the baseline difference between a service that works for a demo and one that remains correct months later with no one watching it.

Full example: github.com/tesddev/fastapi-nginx-service

Understanding Subjects in RxSwift: The Day Everything Clicked

Tesleem Amuda — Thu, 06 Aug 2026 13:32:00 +0000

I remember the exact moment Subjects stopped feeling like magic and started feeling like tools I could actually control.

I had been using RxSwift for a while. Observables made sense. Operators were powerful. Binding worked. But every time I needed to push values into a stream myself — from a network callback, a button action, or some internal state change — I just reached for PublishSubject and moved on. It worked… until it didn’t.

Then one day I sat down and actually looked at the different types of Subjects. That was the turning point. Suddenly a lot of the weird behaviour I’d been fighting made sense, and I started writing cleaner reactive code.

This article is the deep-dive I wish I had back then.

Quick Refresher: What Even Is a Subject?

A Subject is both an Observable and an Observer.

That means:

You can subscribe to it (like a normal Observable)

You can also call .onNext(), .onError(), and .onCompleted() on it yourself

This dual nature is extremely useful, but it’s also where a lot of the confusion (and bugs) come from.

There are four main types in RxSwift:

PublishSubject
BehaviorSubject
ReplaySubject
AsyncSubject

Let’s go through each one properly.

1. PublishSubject – The Event Bus

let publishSubject = PublishSubject<String>()

publishSubject.onNext("A") // Nobody is listening yet → gone forever

let subscription = publishSubject.subscribe(onNext: { print($0) })

publishSubject.onNext("B") // prints "B"

publishSubject.onNext("C") // prints "C"

Key behaviour:

Starts empty
Only emits values to subscribers after they subscribe
Does not keep any history
Perfect for discrete events (button taps, notifications, “something just happened”)

When I reach for it:

UI events that shouldn’t replay
One-shot signals between layers
Any time I truly don’t care about past values

Common pitfall:
People sometimes use PublishSubject for state. Then a late subscriber gets nothing and the UI stays blank. That’s usually a sign you needed a BehaviorSubject instead.

2. BehaviorSubject – State That Always Has a Current Value

let behaviorSubject = BehaviorSubject(value: "Initial")

behaviorSubject.subscribe(onNext: { print("Subscriber 1:", $0) })

// Immediately prints: Subscriber 1: Initial

behaviorSubject.onNext("Updated")

behaviorSubject.subscribe(onNext: { print("Subscriber 2:", $0) })

// Immediately prints: Subscriber 2: Updated

Key behaviour:

Requires an initial value
Always holds the latest value
New subscribers get that latest value immediately
After that, they get new values as they arrive
This is the Subject I use the most in real apps.

Typical use cases:

Current user profile
Selected tab or filter
Loading / error / success state of a screen
Any piece of state that the UI needs right now

Important notes:
Calling .onCompleted() or .onError() terminates it permanently. After that, new subscribers only get the terminal event.

If you need something that never completes and is easier to work with from the UI side, many people prefer BehaviorRelay (from RxRelay). But under the hood it’s still built on BehaviorSubject.

Common pitfall:
Creating a BehaviorSubject with a dummy initial value just to satisfy the compiler, then immediately overwriting it. That dummy value often leaks into the UI for a brief moment.

3. ReplaySubject – “Here’s What You Missed”

let replaySubject = ReplaySubject<String>.create(bufferSize: 2)

replaySubject.onNext("A")

replaySubject.onNext("B")

replaySubject.onNext("C")

replaySubject.subscribe(onNext: { print($0) })

// prints:

// B

// C

Key behaviour:

Keeps a buffer of the last N values
New subscribers receive those buffered values first, then live values
You can also create an unbounded version with .createUnbounded(), but be careful with memory

When it’s useful:

You need a short history (last few locations, last few search results, etc.)
Multiple subscribers joining at different times should all see recent activity
Debugging or logging streams where context matters

Common pitfall:

Using a large or unbounded buffer without thinking. It’s easy to accidentally keep a lot of objects alive and create memory pressure.

4. AsyncSubject – The Final Result Only

let asyncSubject = AsyncSubject<String>()

asyncSubject.subscribe(onNext: { print($0) })

asyncSubject.onNext("A")

asyncSubject.onNext("B")

asyncSubject.onNext("C")

asyncSubject.onCompleted()

// Only now does it print: C

Key behaviour:

Ignores everything until the sequence completes
Then emits only the last value (if any) and completes
If it errors, subscribers get the error instead

This one is the least used in day-to-day iOS work, but it’s perfect for “I only care about the final answer” scenarios — like a long-running calculation or a multi-step process that should only notify when fully done.

Common pitfall:

Forgetting to call .onCompleted(). Without it, nothing ever emits.
Side-by-Side Comparison

Real-World Pitfalls I’ve Hit (and How to Avoid Them)

1. Subjects and Memory Leaks
Subjects themselves don’t cause retain cycles, but the way we hold them does.

class ViewModel {

    let events = PublishSubject<Void>()



    func setup() {

        events

            .subscribe(onNext: { [weak self] in   // ← easy to forget

                self?.doSomething()

            })

            .disposed(by: disposeBag)

    }

}

Always capture self weakly inside the subscription if the subject lives on self.

2. Completing a Subject Too Early
Once a Subject receives .onCompleted() or .onError(), it’s done. Forever. New subscribers only get the terminal event.

If you need a long-lived stream of events, never complete the Subject unless you’re intentionally shutting it down.

3. Using the Wrong Subject for State
This is the most common intermediate mistake.

Need the current value right away when someone subscribes? → BehaviorSubject
Pure event that shouldn’t replay? → PublishSubject
Need a few recent values? → ReplaySubject

Choosing wrong usually shows up as “the second screen that opens doesn’t have the data” or “old events keep firing when they shouldn’t.”

4. Threading Surprises
Subjects are not magically thread-safe in the way some people expect. If you call .onNext from multiple threads without care, you can get race conditions.

In practice I usually make sure all emissions happen on a known scheduler (often MainScheduler for UI-related subjects).

5. Over-using Subjects
Subjects are convenient, but they make your code more imperative. Whenever possible, prefer pure Observables that are created from existing sources (network, notifications, UI controls, etc.). Reach for a Subject only when you genuinely need to push values from outside the reactive chain.

A Practical Pattern I Use Often

final class SomeViewModel {

    // Private so only the ViewModel can emit

    private let _state = BehaviorSubject<ViewState>(value: .loading)



    // Public read-only version

    var state: Observable<ViewState> {

        _state.asObservable()

    }

    func loadData() {

        // ... network call

        _state.onNext(.loaded(data))

        // or

        _state.onNext(.error(error))

    }

}

This pattern keeps the mutability private while still giving the UI a clean Observable to bind to.

Final Thoughts

The day I properly understood the difference between PublishSubject, BehaviorSubject, ReplaySubject and AsyncSubject was the day my RxSwift code got noticeably cleaner. I stopped fighting the library and started choosing the right tool for the job.

You don’t need to memorise every edge case. Just remember the core idea:

Publish → pure events
Behavior → current state
Replay → recent history
Async → final result only

Once that clicks, the rest becomes muscle memory.

If you’ve been using mostly PublishSubject for everything (like I did for a long time), try rewriting one of your ViewModels with the more appropriate Subject types. You’ll feel the difference quickly.

How I Automated Ubuntu Server Hardening with One Script

Tesleem Amuda — Fri, 31 Jul 2026 00:51:54 +0000

Securing and Automating a Cloud Server

The first time I spun up a cloud server, I thought the hard part was over. It wasn't. The server was open to the world: root login enabled, port 22 broadcasting itself to every scanner on the internet, no firewall, and no certificate.

I checked /var/log/auth.log a few hours later and found hundreds of failed login attempts. That was the moment I understood why SSH hardening isn't optional.

Why SSH Hardening Matters

SSH is the front door to your server. By default, that door is wide open: port 22, password authentication allowed, and root login permitted. Automated bots scan millions of IP addresses every hour looking for exactly this.

Hardening SSH means closing that gap before anything else touches the server:

Disable root login: PermitRootLogin no
Disable password authentication and use keys only: PasswordAuthentication no
Move SSH off port 22—I use port 2247
Restrict login to one user: AllowUsers deploy
Disconnect idle sessions after 10 minutes:
- ClientAliveInterval 300
- ClientAliveCountMax 2

These five changes eliminate the vast majority of automated attacks. You're not invisible, but you're no longer an easy target.

What UFW Does

UFW—Uncomplicated Firewall—is Ubuntu's approachable interface to iptables. Rather than writing low-level rules, you express intent:

ufw default deny incoming
ufw default allow outgoing

ufw allow 2247/tcp   # SSH on custom port
ufw allow 80/tcp     # HTTP
ufw allow 443/tcp    # HTTPS

ufw --force enable

Everything not explicitly allowed is blocked. That's the principle of least privilege applied to networking, and it's the same principle that governs good Kubernetes NetworkPolicies, IAM roles, and RBAC.

Start learning it here.

How Let's Encrypt Works

Let's Encrypt is a free, automated Certificate Authority trusted by major browsers. The flow is straightforward:

You point a domain at your server's IP address.
Certbot serves a challenge file over HTTP to prove that you control the domain.
Let's Encrypt issues a certificate valid for 90 days.
Certbot rewrites your Nginx configuration to serve HTTPS and redirect HTTP automatically.
A scheduled task renews the certificate before it expires—no manual work needed.

The result is a free, automatically maintained HTTPS website.

The following command confirms that the renewal pipeline works without modifying your live certificate:

certbot renew --dry-run

What Idempotency Means—and Why It Matters

Idempotent means that running the same operation twice produces the same result as running it once.

It sounds academic. It isn't.

In practice, it means:

If deploy already exists, skip it instead of returning an error.
If the certificate already exists, skip it instead of requesting a duplicate.
If packages are already installed, apt-get handles them gracefully.

Without idempotency, rerunning a setup script after a partial failure could lock you out of your own server. With it, you can run the script confidently after any interruption.

This habit carries forward into Ansible, Terraform, and every automation tool you'll use at a professional level.

The Script

The complete script is available here:

github.com/tesddev/server-bootstrap

On a fresh Ubuntu 22.04 server, one command does everything:

sudo bash setup.sh

In order, the script:

Updates the system and installs essential packages.
Creates a non-root deploy user and copies in the SSH key.
Hardens SSH by changing the port, disabling root login and password authentication, and setting an idle timeout.
Configures UFW with an explicit allowlist.
Installs Nginx and serves a custom page.
Obtains a Let's Encrypt certificate using Certbot.

What You Get at the End

SSH restricted to key authentication on a non-standard port
A firewall permitting only necessary traffic
A live website at https://tes-devops.duckdns.org with a valid, automatically renewing certificate
A script you can run on any new server today or six months from now

The Real Lesson

Manual server setup doesn't scale, and more importantly, it doesn't reproduce reliably. The same steps performed by two different people on two different days will produce two subtly different servers.

Scripts don't have that problem.

Writing small, idempotent automation scripts is one of the most transferable habits in DevOps. Everything that follows—Ansible playbooks, Terraform modules, and Kubernetes manifests—is this same idea applied at a larger scale.

➡️ View the server-bootstrap repository on GitHub

Automated User Management with Bash Script

Tesleem Amuda — Mon, 01 Jul 2024 15:36:41 +0000

Managing user accounts in a Linux environment can be tedious, especially when dealing with a large number of new employees. To simplify this process, we can use a Bash script to automate user and group creation, ensuring appropriate permissions and logging. Below is a detailed breakdown of a Bash script that accomplishes this.

Script Overview

The script reads a text file containing usernames and group names, creates users and groups as specified, sets up home directories with appropriate permissions and ownership, generates random passwords for the users, and logs all actions to /var/log/user_management.log. It also securely stores the generated passwords in /var/secure/user_passwords.txt.

Script Breakdown

#!/bin/bash

# Check if the input file is provided
if [ $# -eq 0 ]; then
    echo "Usage: $0 <user_list_file>"
    exit 1
fi

user_list_file="$1"

# Log and password file paths
log_file="/var/log/user_management.log"
password_file="/var/secure/user_passwords.txt"

# Create the necessary directories and set permissions
mkdir -p /var/log
mkdir -p /var/secure
touch "$log_file"
touch "$password_file"
chmod 600 "$password_file"

Input File Check: The script starts by ensuring that an input file is provided. This file should contain the list of users to be managed.
Directory and File Setup: It creates directories and files necessary for logging and storing passwords. Permissions are set to ensure security.

# Function to log actions
log_action() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> "$log_file"
}

Logging Function: A function log_action is defined to log each action taken by the script. This helps in auditing and troubleshooting.

# Read the user list file
while IFS=';' read -r username groups; do
    # Remove whitespace
    username=$(echo "$username" | xargs)
    groups=$(echo "$groups" | xargs)

Reading the User List: The script reads each line from the input file, expecting a username and groups separated by a semicolon. Whitespace is trimmed to ensure clean data.

    # Ensure all specified groups exist
    for group in $(echo "$groups" | tr ',' ' '); do
        if ! getent group "$group" >/dev/null; then
            groupadd "$group"
            if [ $? -eq 0 ]; then
                log_action "Created group $group"
            else
                log_action "Failed to create group $group"
                continue
            fi
        else
            log_action "Group $group already exists"
        fi
    done

Group Management: The script checks if each specified group exists and creates it if it doesn't. Actions are logged accordingly.

    # Create the personal group
    if ! getent group "$username" >/dev/null; then
        groupadd "$username"
        if [ $? -eq 0 ]; then
            log_action "Created group $username"
        else
            log_action "Failed to create group $username"
            continue
        fi
    else
        log_action "Group $username already exists"
    fi

Personal Group Creation: For each user, a personal group with the same name is created if it doesn't already exist.

    # Create the user with the personal group
    if ! id -u "$username" >/dev/null 2>&1; then
        useradd -m -g "$username" -s /bin/bash "$username"
        if [ $? -eq 0 ]; then
            log_action "Created user $username with personal group $username"

User Creation: If the user doesn't already exist, the script creates the user account, assigns the personal group, and sets the default shell to bash.

            # Set the user's additional groups
            if [ -n "$groups" ]; then
                usermod -aG "$groups" "$username"
                if [ $? -eq 0 ]; then
                    log_action "Added user $username to groups $groups"
                else
                    log_action "Failed to add user $username to groups $groups"
                fi
            fi

            # Generate a random password
            password=$(openssl rand -base64 12)
            echo "$username:$password" | chpasswd
            if [ $? -eq 0 ]; then
                log_action "Set password for user $username"
            else
                log_action "Failed to set password for user $username"
            fi

            # Save the password securely
            echo "$username,$password" >> "$password_file"
        else
            log_action "Failed to create user $username"
        fi
    else
        log_action "User $username already exists"
    fi

Additional Group Assignment: If additional groups are specified, the user is added to these groups.
Password Management: A random password is generated and set for the user. The password is stored securely in a file with restricted permissions.

    # Set home directory permissions
    chmod 700 "/home/$username"
    chown "$username:$username" "/home/$username"
    log_action "Set permissions for /home/$username"
done < "$user_list_file"

log_action "Script execution completed."

Home Directory Permissions: The script sets strict permissions on the user's home directory to ensure privacy and security.

Key Features

Group Creation: Ensures all specified groups exist before assigning users to them, preventing errors and ensuring proper group membership.
User Creation: Creates users with personal groups and sets up their home directories with appropriate permissions.
Password Generation: Generates random, secure passwords for new users and stores them securely.
Logging: Logs all actions to a log file for audit purposes and troubleshooting.

Conclusion

This script is a robust solution for managing user accounts in a Linux environment. By automating the creation and management of users and groups, it saves time and reduces the potential for errors.