DEV Community: Tazoh Yanick

How I Shrank a Next.js Image by 80% in My First Week of Docker

Tazoh Yanick — Thu, 04 Jun 2026 09:33:10 +0000

I'm a full-stack developer pivoting toward Site Reliability Engineering and Platform Engineering. I'm based in Yaoundé, planning to move to Canada later this year, and I've decided the next 5 months are about turning my full-stack background into infrastructure skills that hold up against AI automation. Week 1 was Docker. I'd never used it before.

Here's what I learned, the mistakes I made, and the optimization story I didn't expect.

Days 1-2: Foundations and the image-vs-container confusion

Day 1 was installation and concepts. Day 2 was my first real container — a tiny Node.js HTTP server, containerized from scratch.

The conceptual flip everyone hits on Day 2 hit me too. When my mentor asked me what an image was versus a container, I answered confidently — and got it backwards. I said the image was the thing you share and the container was the read-only template. It's the opposite.

Here's the version that finally stuck for me:

An image is the read-only blueprint. A container is a running instance created from an image. Images get shared via Docker Hub. Containers run locally.

The other concepts that took a beat to land:

The Docker daemon doesn't just relay commands, it does the actual work. Your terminal (the client) is a waiter; the daemon is the kitchen. When you type docker run, the daemon builds, runs, pulls, and manages everything.
Image layers exist for caching. Change one line of source code and only the affected layer rebuilds. Push to Docker Hub and only changed layers go over the network.

By end of Day 2 I had a 46 MB hello-world image pushed to Docker Hub. Small, but mine.

Day 3: The optimization story

This is where Docker stopped being academic.
The plan for Day 3 was to containerize my actual deployed project: an AI immigration assistant I built for the recent DEV Gemma 4 Challenge. Same Next.js code that's running in production on Vercel. I wrote a multi-stage Dockerfile, used npm ci --omit=dev, picked the Alpine Node base. Built the image.

It came out to 1.37 GB.

That's not a working Dockerfile — that's a broken one with a working app inside it. So I did what an SRE would actually do: I ran docker history and looked at where the bytes lived.

Layer	Size
`node_modules` (from deps stage)	493 MB
`.next` (full build output)	326 MB
Node 20 Alpine base	130 MB
Everything else	tiny

Two problem layers, 819 MB combined. The diagnosis was clear: even with --omit=dev, my node_modules was carrying packages npm classified as devDependencies but Next.js actually needs at runtime. And the full .next directory was carrying build caches, source maps, and intermediate compiler artifacts I'd never use.

The fix was a Next.js feature called standalone output mode. One line in next.config.ts:

tsoutput: "standalone"

What this does: Next.js traces the compiled application and bundles only the files genuinely needed at runtime into .next/standalone/. The standalone output for my project has 10 directories in its node_modules — React, ReactDOM, Next.js itself, the SWC compiler, sharp, and a few small utilities. That's it. Total standalone size: 18 MB.

I rewrote the Dockerfile to copy only .next/standalone and .next/static instead of the whole node_modules and .next directories. One more change: ENV HOSTNAME=0.0.0.0, because standalone defaults to localhost and that means Docker port mapping doesn't work.

Rebuilt.

Version	Image Size	Compressed on Docker Hub
`:1.0`	1.37 GB	—
`:1.1`	269 MB	64.6 MB

80% reduction. 5x smaller. Same app, same Node base, same architecture.

The lesson wasn't "Docker is hard." It was: capable defaults aren't always sufficient defaults. Real optimization comes from looking at where the bytes are and applying the right targeted fix.

Day 4: Multi-container systems with Compose

Day 4 was about the leap from one container to systems of containers. I built a small Node API + Postgres stack, orchestrated with a docker-compose.yml.

The moment that made Compose click for me was this log line, right after I ran docker compose up -d:

✔ Container lab-03-compose-multi-container-db-1   Healthy   6.2s
✔ Container lab-03-compose-multi-container-api-1  Started   6.5s

The database was declared _healthy _at 6.2 seconds. The API started at 6.5 seconds. The 300 ms gap was Compose waiting — specifically, depends_on with condition: service_healthy
waiting for Postgres's pg_isready healthcheck to pass before letting the API container come up. Without that gate, the API would start instantly and try to connect to a Postgres that wasn't ready yet, get ECONNREFUSED, and crash.

That's production-shape orchestration: not just "start everything in order" but "start everything in readinessorder."

The other concept that landed: service discovery by name. Inside the API container, my Node code connects to Postgres using the hostname db. Not localhost. Not an IP. Just db. Compose creates a private network where the service name is the hostname, automatically. I tested it from inside the running container:

/app # ping db
PING db (172.19.0.2): 56 data bytes
64 bytes from 172.19.0.2: seq=0 ttl=64 time=2.5 ms

That's the entire conceptual basis for how Kubernetes services work too, by the way. Day 4 taught me orchestration vocabulary I'll need in Week 12 when CKA prep starts.

One more thing worth knowing: volumes. I tested it explicitly. docker compose down keeps the named volume — my Postgres data survived the restart. docker compose down -v removed the volume and the data was gone. That distinction matters for any stateful production service.

Day 5: Networking deep dive (the gotcha that bites everyone)

Day 5 closed Week 1 with the one Docker concept I hadn't drilled by hand yet — networks.
Docker has three network drivers worth knowing:

Bridge: single-host private network. ~90% of what you'll ever use.
Host: no network isolation at all; container shares the host's network stack directly. Performance-critical use cases only.
Overlay: multi-host networking for Docker Swarm or distributed orchestrators. Conceptual predecessor to Kubernetes networking.

The gotcha that bites everyone is this: the default bridgenetwork **, the one that ships with Docker out of the box — does not give you DNS resolution by container name.** If two containers attach to the default bridge, they can only reach each other by IP address. And container IPs change every time you restart.

Custom bridge networks (the ones you create with docker network create my-network) do give you automatic DNS by name. Same driver, totally different behavior.

This is why every real-world Docker setup creates custom networks. It's also why docker-compose.yml automatically creates a custom network for your stack — that's the entire reason Compose works the way it does.

The rule worth memorizing: never use the default bridge in production. Always create a custom network.

I tested it with two unrelated containers — web1and web2— attached to a network I created manually. From inside web1:

/ # ping -c 3 web2
PING web2 (172.19.0.3): 56 data bytes
64 bytes from 172.19.0.3: seq=0 ttl=64 time=1.944 ms

web2resolved to 172.19.0.3 automatically. No configuration, no IP hardcoding. The container name became the hostname.

Three things I'd tell another Docker beginner

Verify everything you write to a file. I corrupted a README this week by piping a heredoc that swallowed a special character mid-stream. The file ended mid-sentence, and I didn't notice until commit. After every cat > file << EOF, run cat file to confirm what landed. This is a real DevOps habit. Verify state, don't assume.

Multi-stage builds aren't optional. They're how you avoid 1 GB images. A single-stage Dockerfile for a typical Next.js project will produce an image somewhere between 800 MB and 1.5 GB. Separating build from runtime, copying only the runtime artifacts forward, is the basic discipline. Combine it with framework-specific tricks (like Next.js standalone), and you get 80% reductions for free.

The default bridge network is a trap. Always create a custom network. I covered this above but it bears repeating because it's the kind of thing people learn the hard way at 2 AM when their containers can't talk to each other on the default bridge. Custom networks come with automatic DNS resolution. Default doesn't. Just use custom.

What's next

Week 2 starts AWS Solutions Architect Associate prep — the next chapter in the SRE pivot. The plan: certification by end of June, then Terraform, networking deep-dive, Kubernetes, and CKA before the move to Canada.
Everything from this week lives on GitHub: github.com/t-yanick/sre-portfolio-2026. Three labs, real READMEs, the full optimization story documented with docker history outputs and Dockerfiles.

The deployed AI immigration assistant — now also available as a 64.6 MB Docker image on Docker Hub at tyanick237/gemma-canada-assistant:1.1 — is at gemma-canada-assistant.vercel.app.

Week 1 down. Twenty-one to go.

Building a Cameroon-Aware Immigration Assistant with Gemma 4

Tazoh Yanick — Sun, 24 May 2026 20:41:39 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

Most refusals for Cameroonian Express Entry applicants come from the same handful of patterns. I built a Gemma 4–powered second-reviewer that flags them before submission.

What I Built

The Canada Immigration Assistant is a second-reviewer tool for African applicants navigating Canadian immigration. It addresses three of the most common refusal patterns IRCC cites, all in one place.

The reference letter generator takes a user's NOC code, their actual day-to-day duties, and employer details — then rewrites the duties in the applicant's own voice (so IRCC doesn't see verbatim NOC text), produces a 7-to-10-point reference-letter checklist, and assembles a full copy-paste-ready letter outline.

The proof of funds + employment legitimacy analyzer checks the applicant's funds against the official IRCC table for their family size, flags fund-source issues (microfinance, mobile money, gifts without donor documentation), and validates employment legitimacy across Cameroon's public, private, mission, and vacataire sectors. It also surfaces CEC and job-offer exemptions up front, so applicants who don't need POF know it immediately.

The visitor visa home ties analyzer rates an applicant's ties to home, builds a category-by-category inventory across employment, family, property, financial, and travel history, and flags dual-intent risks specific to the applicant's situation.

What makes it different from generic AI immigration tools: it knows that a Cameroonian government teacher is documented by l'acte d'intégration, not CNPS — and many other locally-specific rules that a globally-trained model gets confidently wrong by default. All three features are powered by Gemma 4.

Try it: gemma-canada-assistant.vercel.app

The deeper story: I wrote about the prompt-engineering lessons here.

Demo

Live app: gemma-canada-assistant.vercel.app

The reference letter feature, with all twelve supported NOC codes and three-way navigation:

A real Gemma 4 response from the proof of funds analyzer, flagging microfinance and missing CNPS for a private-sector applicant:

Code

github.com/t-yanick/gemma-canada-assistant

The README walks through architecture (Next.js 16 App Router, Tailwind v4, three API routes, a shared Gemma client, three system prompts, twelve IRCC-verified NOC entries), setup, and local development.

How I Used Gemma 4

I used google/gemma-4-31b-it:free via OpenRouter throughout the project, with a Google AI Studio API key plugged in as BYOK. Total cost to build, test, and deploy: $0.

Three things mattered for the project, and Gemma 4 handled all three well.

Structured JSON output. Every API endpoint in the app expects a typed response from Gemma — RewriteApiResponse, PofApiResponse, VisitorVisaApiResponse. I used Gemma's JSON mode (response_format: { type: 'json_object' }) and defined the exact schema inside each system prompt. The model returned valid, parseable JSON on the first attempt, the overwhelming majority of the time. For the rare exceptions, the shared client falls back to a defensive parser that strips markdown fences before parsing.

Long, rule-dense system prompts. Each prompt is roughly 100-150 lines of dense domain knowledge: which Cameroonian institutions are microfinance vs commercial banks, how l'acte d'intégration differs from CNPS for public-sector workers, which fund sources require seasoning, when an applicant qualifies for exemption. Gemma 4 held all of it across the conversation without drifting.

Retry-on-5xx for reliability. The free Google AI Studio tier occasionally returns transient 500 errors. The shared callGemma client retries once on 5xx with a 1.5-second delay, which made the difference between a flaky demo and a reliable product.

A real Gemma 4 response, lightly trimmed, from the POF analyzer for an applicant with funds at Express Union microfinance and cash-paid employment:

{
  "exemption_status": "not_exempt",
  "pof_status": "borderline",
  "pof_amount_check": "The applicant has 25,000 CAD, which exceeds the required 23,360 CAD. However, this is a slim margin; a buffer of 2,000-3,000 CAD is recommended to account for exchange rate fluctuations.",
  "fund_source_flags": [
    "IRCC does not accept funds held in microfinance institutions like Express Union because they are not considered liquid commercial bank accounts. These funds must be transferred to a commercial bank (e.g., Afriland First Bank, BICEC, Ecobank) to be valid."
  ],
  "employment_legitimacy_flags": [
    "Cash payment without CNPS registration is a strong red flag for a private sector worker. IRCC may view this as undocumented or informal employment, which can lead to a rejection of the work experience claim."
  ],
  "required_documents": [
    "Bank letter from a commercial bank on official letterhead, dated within 1 month, stating account number, opening date, current balance, 6-month average balance, and outstanding debts.",
    "6 months of stamped bank statements from a commercial bank showing salary deposits.",
    "CNPS attestation to prove legal employment status in the private sector."
  ],
  "recommended_next_steps": [
    "Immediately open a commercial bank account and transfer the funds from Express Union to begin establishing a 6-month average balance.",
    "Request your employer to provide a formal letter of employment and start registering with CNPS to legitimize your work history.",
    "Begin depositing your cash salary into your new commercial bank account every month to create a paper trail of income."
  ],
  "regional_context_note": "In Cameroon, microfinance and cash-based salaries are common and legitimate ways of managing finances. However, IRCC requires strict adherence to commercial banking standards and social security registration to verify the legitimacy of funds and employment."
}

That single response identified two refusal-pattern risks, listed the documents the applicant needs, sequenced four concrete next steps, and acknowledged the local context without moralizing about it. The same model, with a generic prompt, would have given generic advice that didn't apply to Cameroon at all. The difference is entirely in the system prompt.

Lessons Learned

Three things I'd tell another developer building with Gemma 4:

Constrain the output, narrow the decision space. Gemma 4 is reliable when you use JSON mode with an explicit schema, and unreliable when you let it improvise. Define the shape you want, define the values it can produce, and the model will stay inside the box.

It's a general-purpose model — domain context goes in the prompt. Don't expect Gemma to know your context. Teach it, explicitly. For me, that meant four rounds of iteration: ship a prompt, test with real applicant data, find what the model got wrong by local standards, refine. The fourth round held up against two real anonymized IRCC refusal letters.

Deploy it as a second reviewer, not an oracle. This tool isn't replacing immigration lawyers — it's catching the kinds of mistakes a human would, if a human had the time and patience to review every applicant's file before submission. Framing it that way changed both the product and how I wrote about it.

What Gemma 4 Doesn't Know About Cameroon — and What That Taught Me About Building AI for the Real World

Tazoh Yanick — Thu, 21 May 2026 10:06:12 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

When my friend contacted me on WhatsApp with a crying 😢 emoji, my heart skipped. I asked what was wrong, and she sent me her Express Entry refusal letter. IRCC had denied her application — no CNPS affiliation, and the funds in her account were held in a microfinance institution, which the officer did not consider transferable. I read the letter line by line. What made it hard wasn't just that she'd been refused — it was that I understood every reason. I'm in the same queue, waiting for my own decision, and over the years I've helped a lot of friends and family enter the pool and fill their ePR applications. If I had seen her application before she submitted it, I could have flagged these things. That thought sat with me for days. When an email from the DEV Community landed about a challenge to build something creative and useful, it was the push I needed.

So I decided to build a Gemma 4–powered assistant that flags these mistakes before an applicant hits submit. The goal isn't to replace immigration lawyers or consultants. It's to give ordinary applicants — especially people navigating these systems alone — a second pair of eyes before costly mistakes become refusals.

Why Gemma 4

This project needed a model with structured reasoning capability, able to handle country-specific rules, and cost-effective.

Gemma 4 was the right fit because it gave very structured JSON output, and could hold long prompts without drifting from the real results.

I didn't do a technical review with other models, but I read about Gemma 4 and was convinced it could do the job, so I started building.

It actually mattered that I could run it via OpenRouter for free, because this proves that any developer in a place where resources are limited can conveniently build serious AI apps with Gemma 4.

On paper, Gemma 4 was the right model. The real test was what it would do when given a Cameroonian applicant's data.

Where Gemma 4 got it wrong

I ran my first test, in which I entered the data and details of a computer science and ICT government secondary school teacher. This is, of course, a typical example of the kind of applicant I have personally helped, so I know what a correct output should look like.

The output told me to translate any French documents into English. For the Cameroonian context, which was my test data, this is wrong — because Cameroon, just like Canada, is a bilingual country, and documents in French and English are both accepted by IRCC. Worth noting is that Gemma was not stupid. It simply didn't have the local context, because globally speaking, that advice for someone from Cape Verde or Equatorial Guinea is perfect. Gemma applied a firm rule without considering the special status of Cameroon.

With the same test data, Gemma flagged the teacher for missing CNPS. This was wrong, because civil servants in Cameroon are documented by l'acte d'intégration. Globally, Gemma's logic was correct, but locally it didn't hold.

Looking at the output again, it clicked: the two scenarios above were not two separate bugs — it was Gemma using the same reasoning pattern. It reasons well, but it didn't have the Cameroon context. The fix wasn't a better model. It was giving Gemma the context it didn't have.

The fix

After my first test, it dawned on me that I had to teach Gemma 4 about the Cameroonian context with regard to what I was building.

I made Gemma 4 understand there is a real difference between employees of the public and private sectors: civil servants are documented by l'acte d'intégration, while CNPS affiliation applies to private sector workers. I also taught it the bilingual rule — never recommend French-to-English translation, because Cameroon is bilingual, just like Canada. And I taught it to preserve local terminologies like "Lower Sixth" and "Probatoire," because that is what tells IRCC the employment letter duties are not copied verbatim from the NOC code.

It is worth mentioning that it wasn't a single prompt that produced the best results. Four rounds of testing with a range of data, finding gaps, and refining the prompts is what got us there. For example, a later test surfaced a gap that needed addressing: the microfinance / commercial-bank intermediary funds transferability issue, and the payslip-versus-bank-deposit consistency check.

Gemma 4 is actually a very capable model. With a precise domain context, it is reliable enough to produce locally correct output. No fine-tuning needed — just precise prompts.

Two real refusals

This isn't theoretical. Below are two real IRCC refusal letters from Cameroonian applicants, anonymized for this article.

Exhibit A — a web designer applying as NOC 21233, cited for three failures: cash payment without CNPS affiliation, payslip amounts not matching bank deposits, and proof-of-funds documents on Norton Financial letterhead carrying UBA's SWIFT code (UNAFCMCX), which the officer read as evidence that the funds were not actually transferable.

Exhibit B — funds held at LA MEC microfinance with no proof of a commercial-bank pathway, plus an acte de donation submitted without the donor's bank statements to back it up. The officer concluded the funds were not reliably transferable.

Every ground cited in both letters — cash payment, missing CNPS, payslip-deposit mismatch, microfinance via commercial-bank intermediary, gift deed without donor records — is flagged by the tool before submission.

What this means

Gemma 4 is a capable open model, freely accessible and running on a developer's laptop without infrastructure or budget. As a developer whose laptop is not powerful enough to train models, I was still able to build something unique and useful for my community.

Nobody in San Francisco was going to build a Cameroon-aware immigration assistant. Not because the developers there are not smart, but because Express Entry refusals in Yaoundé are not a problem they see. The people best placed to build for a niche are the people inside it. Open, capable models make that possible.

Gemma 4 is for builders everywhere who understand real problems that nobody else is going to solve for them.