Skip to Content
DojOps: AI-powered DevOps automation. Learn more →
TutorialsEnhance a Next.js Project

Enhance a Next.js project

Scan, analyze, and improve an existing project’s DevOps setup.

Difficulty: Beginner Duration: 30 minutes What you’ll build: A production-ready DevOps configuration for a Next.js app, including an enhanced CI workflow with caching and security scanning, a hardened multi-stage Dockerfile, and a quality score above 85/100.


What you’ll learn

  • Initializing project context so DojOps knows your stack before generating anything
  • Running a quality check that gives you specific, actionable findings instead of vague advice
  • How agent routing picks the right specialist for your prompt without you choosing one
  • Enhancing existing CI workflows while keeping the steps you already have
  • Hardening a Dockerfile with pinned versions, non-root users, and health checks

Prerequisites

  • Node.js >= 20 (nodejs.org )
  • Git installed
  • An API key from a supported LLM provider (OpenAI, Anthropic, DeepSeek, Gemini, or a local Ollama instance)

No prior DevOps experience needed. Already have DojOps installed? Skip to Step 2.


Workshop steps

Step 1: Install DojOps

npm i -g @dojops/cli

Check that it’s working:

dojops --version
@dojops/cli v1.1.6

Run the environment check too. If anything shows warn or error here, fix it before moving on:

dojops doctor
DojOps Doctor Node.js v20.11.1 ok npm v10.2.4 ok git v2.43.0 ok Config ~/.dojops/ ok

Step 2: Clone the example project

We’re working with a minimal Next.js portfolio site. It has a GitHub Actions workflow and a Dockerfile, but both have gaps on purpose. Good enough to ship, not good enough to trust.

git clone https://github.com/dojops/example-nextjs.git cd example-nextjs

Take a look at what’s there:

ls -la
total 48 drwxr-xr-x 8 user user 4096 Mar 20 10:00 . drwxr-xr-x 12 user user 4096 Mar 20 09:59 .. drwxr-xr-x 3 user user 4096 Mar 20 10:00 .github -rw-r--r-- 1 user user 312 Mar 20 10:00 .dockerignore -rw-r--r-- 1 user user 198 Mar 20 10:00 .gitignore -rw-r--r-- 1 user user 743 Mar 20 10:00 Dockerfile -rw-r--r-- 1 user user 1204 Mar 20 10:00 next.config.ts -rw-r--r-- 1 user user 1891 Mar 20 10:00 package.json drwxr-xr-x 4 user user 4096 Mar 20 10:00 src

You’ve got Dockerfile, .github/workflows/ci.yml, and a Next.js app under src/. No Docker Compose, no Makefile. The CI and Dockerfile both have issues we’ll find in a minute.


Step 3: Configure a provider

Pick whichever LLM provider you have access to:

# OpenAI dojops provider add openai --token sk-... # Anthropic dojops provider add anthropic --token sk-ant-... # DeepSeek dojops provider add deepseek --token sk-... # Local Ollama (no token needed) dojops provider add ollama

Confirm it’s connected:

dojops auth status
Provider: openai Model: gpt-4o Status: authenticated

If you see unauthenticated, double-check your token. The Provider Management page has provider-specific details.


Step 4: Initialize the project

dojops init scans the project and records what it finds. Your source code isn’t sent anywhere. DojOps only reads filenames and DevOps config structure.

dojops init
Initializing DojOps... Languages detected: TypeScript, JavaScript, CSS CI/CD platforms: GitHub Actions (.github/workflows/ci.yml) Container files: Dockerfile, .dockerignore DevOps files found: .github/workflows/ci.yml Dockerfile .dockerignore .gitignore Recommended agents: github-actions-specialist dockerfile-specialist Project context saved to .dojops/context.json

The .dojops/context.json file is what every subsequent command reads from. It tells the LLM what’s already in your project so it won’t generate things that conflict with what you have.


Step 5: Check DevOps maturity

Run the quality check:

dojops check
DevOps Quality Check Score: 62/100 (Basic) Findings: warning CI workflow lacks caching for node_modules warning No security scanning step in CI pipeline warning Dockerfile does not pin base image digest info No Docker Compose file for local development info No Makefile or Justfile for task automation Missing files: SECURITY.md CODEOWNERS renovate.json or dependabot.yml

62/100 is typical for a project that “works” but hasn’t been hardened. Notice how specific the findings are. Not “improve your CI” but “CI workflow lacks caching for node_modules.” You know exactly what to fix, which makes the next steps fast.


Step 6: Enhance the CI workflow

Feed the quality check findings into your prompt. Use --execute to write the changes to disk with an approval step:

dojops --execute "Enhance the GitHub Actions CI workflow with dependency caching, security scanning, and Docker image building"

DojOps first decomposes your goal into a TaskGraph — a dependency-ordered set of tasks:

◇ Tasks decomposed ◇ Enhance the GitHub Actions CI workflow... (4 tasks) ──────────╮ │ │ │ analyze-existing-ci github-actions [cicd-specialist]: │ │ Analyze the existing CI workflow structure │ │ create-docker-build-action github-actions [docker-specialist]:│ │ Create composite action for Docker builds │ │ (after: analyze-existing-ci) │ │ create-security-scan-action github-actions [security-auditor]:│ │ Create composite action for security scanning │ │ (after: analyze-existing-ci) │ │ update-ci-workflow github-actions [cicd-specialist]: │ │ Update the main CI workflow with all improvements │ │ (after: create-docker-build-action, create-security-scan) │ │ │ ├─────────────────────────────────────────────────────────────────╯ ◆ Plan saved as plan-cb41398f

Then it shows a pre-flight summary with risk assessment and asks for approval:

◇ Pre-flight Summary ──────────────────────╮ │ │ │ Plan: plan-cb41398f │ │ Tasks: 4 tasks │ │ Risk: LOW │ │ Skills: github-actions │ │ │ ├────────────────────────────────────────────╯ ◇ Impact Summary ───────────╮ │ │ │ Files to write: ~4 │ │ Verification: github-actions │ │ Risk level: LOW │ │ │ ├─────────────────────────────╯ ◇ Apply this plan? (y/n): y

Type y to execute. DojOps runs each task in dependency order, generates the files, and writes them to disk. Existing files get a .bak backup before being overwritten.

Tip: Use --yes to auto-approve (dojops --execute --yes "..."). Use plain dojops "..." without --execute to preview what would be generated without writing any files.


Step 7: Enhance the Dockerfile

The quality check flagged unpinned base images. In practice, floating tags cause silent breakage when upstream images update. Fix it:

dojops --execute "Enhance the Dockerfile with pinned base image versions, security hardening, and build caching"

DojOps decomposes this into tasks, shows the plan, and asks for approval — same flow as Step 6. After you approve:

◇ Executing task: analyze-dockerfile [dockerfile-specialist] ◇ Executing task: harden-dockerfile [dockerfile-specialist] Changes to Dockerfile: + Pinned node:20.11.1-slim (was node:20-slim with floating tag) + Non-root user (USER nextjs:nodejs, uid 1001) + Optimized COPY order for layer cache efficiency + HEALTHCHECK directive for container orchestration + OCI image labels for traceability Written: Dockerfile (backup: Dockerfile.bak)

Pinned versions prevent “works on my machine” failures. The non-root user shrinks your attack surface. The health check tells Kubernetes and Docker Compose when the container is actually ready to serve traffic, not just started.


Step 8: Verify your improvements

Re-run the quality check and see what changed:

dojops check
DevOps Quality Check Score: 86/100 (Good) Findings: info Consider adding a SECURITY.md info Consider adding Dependabot or Renovate for dependency updates info Consider adding a Makefile for common tasks Missing files: SECURITY.md CODEOWNERS renovate.json or dependabot.yml

62 to 86. The warning-level findings are gone. What’s left are info items: nice-to-haves rather than real gaps. Check the audit trail to see what was recorded:

dojops history list
◇ Plans (2) ───────────────────────────────────────────────────────────╮ │ │ │ plan-a1b2c3d4 COMPLETED 3/20/2026 Enhance the GitHub Actions CI │ │ workflow with dependency caching│ │ plan-e5f6a7b8 COMPLETED 3/20/2026 Enhance the Dockerfile with │ │ pinned base image versions │ │ │ ├───────────────────────────────────────────────────────────────────────╯

Every operation is hash-chained. dojops history verify confirms the chain is intact and nothing was tampered with.


Try it yourself

  1. Run dojops "Create a Docker Compose file for local development with hot reloading" and look at the volume mount strategy it picks for Next.js.

  2. Three info items remain. Use DojOps to generate SECURITY.md and renovate.json, then re-run dojops check. See how high the score goes.

  3. Run dojops history verify, then dojops history show plan-a1b2c3d4. The hash-chain format is how the audit log stays tamper-evident.


Troubleshooting

dojops: command not found after installation Your shell’s PATH probably doesn’t include npm globals. Run npm bin -g to find the bin directory, then add it: export PATH="$PATH:$(npm bin -g)".

dojops auth status shows unauthenticated The token was rejected. Check for leading/trailing whitespace when you paste it. Run dojops provider add <provider> --token <token> again with the corrected value.

Quality check score doesn’t improve after enhancement DojOps generates improvements based on its scan at init time. If you changed DevOps files manually after init, run dojops init again to refresh the context before re-checking.

The .bak file is missing Backups are created only when DojOps modifies an existing file. If you used --yes and don’t see a .bak, check .dojops/history/. DojOps logs the original content there too.


What you learned

You took a working Next.js project from a 62 to an 86 quality score in two commands. DojOps built context during init, used it to find specific gaps during check, then routed your prompts to the right specialist agents without you needing to pick one. The CI workflow kept its existing steps while gaining caching and security scanning. The Dockerfile went from a floating base tag to pinned versions with a non-root user. Everything was logged in a tamper-evident audit trail.


Next steps