Forem: Alvarito1983

Claude Code: The Complete Guide from Zero to Autonomous Development

Alvarito1983 — Tue, 07 Apr 2026 09:15:58 +0000

Claude Code is not a code editor plugin. It's not a chatbot you paste code into. It's an autonomous agent that lives in your terminal, reads your entire codebase, plans multi-step work, executes it, checks the results, and fixes what breaks.

This guide covers everything: what it is, how it thinks, how to set it up, and how to use it at a level most developers haven't reached yet.

What Claude Code actually is
How it works under the hood
Installation and setup
The CLAUDE.md file — your most important tool
Writing prompts that work
Phase-based development
Slash commands and shortcuts
What Claude Code can and cannot do
Workflow patterns that scale
Common mistakes and how to avoid them

1. What Claude Code actually is

Most AI coding tools work like this: you write a prompt, you get code back, you copy it somewhere.

Claude Code works differently. It has direct access to:

Your file system (read and write)
Your terminal (execute bash commands)
Your project structure (it reads everything before acting)

When you give it a task, it doesn't guess at your codebase. It reads the relevant files first, builds a mental model of what exists, then acts. It can create files, edit files, run builds, check logs, install packages, and verify its own output.

The mental model shift: stop thinking of it as a code generator. Think of it as a developer you can delegate to.

2. How it thinks

Claude Code follows a loop:

1. Read context (files, structure, your CLAUDE.md)
2. Plan the approach
3. Execute step by step
4. Verify output
5. Fix problems it finds
6. Report back

This loop runs autonomously. It doesn't wait for you to approve each file. It moves forward, and if something fails (a build error, a missing dependency, a broken import), it diagnoses and fixes it.

The implication: your job is to set context well at the start, then review the result at the end. Not to supervise every step.

3. Installation and setup

Claude Code runs as a CLI tool. Install it via npm:

npm install -g @anthropic-ai/claude-code

Authenticate with your Anthropic account:

claude

This opens a browser for OAuth. Once authenticated, you're ready.

To start a session in your project:

cd your-project
claude

That's it. Claude Code will read your project structure on first use.

Platform notes:

macOS/Linux: works natively
Windows: use PowerShell or CMD. Note that && chaining doesn't work in PowerShell — Claude Code knows this and uses separate commands automatically

4. The CLAUDE.md file — your most important tool

This is the single highest-leverage thing you can do. A CLAUDE.md file at the root of your project is read automatically at the start of every session. It's your persistent context.

Without it: Claude Code reads your code and makes reasonable guesses about conventions, stack, and intent.

With it: Claude Code knows exactly what you're building, how it's structured, what decisions you've already made, and what rules to follow.

What to put in CLAUDE.md

# Project name and purpose
Brief description of what this is and what it does.

## Tech stack
- Framework: React 18 + Vite
- Backend: Node.js + Express
- Styling: CSS custom properties (no Tailwind)
- Icons: Lucide React
- Auth: JWT

## Architecture
Explain the key structural decisions. What talks to what.
Where the main files live. How modules are organized.

## Conventions
- One component per file
- No inline styles — use CSS variables
- All API routes under /api/
- Error responses always { error: string }

## Design system (if applicable)
Color tokens, spacing rules, typography scale.
The more specific, the better the UI output.

## Infrastructure
- Dev path: /your/local/path
- Production: where it runs
- Ports: which service runs where
- CI/CD: how deploys work

## Known issues / current state
What's in progress. What's broken. What to avoid.

Initialize it automatically

claude
/init

This generates a starter CLAUDE.md from your existing project. Edit and expand it — the generated version is a starting point, not a finished document.

CLAUDE.md at multiple levels

You can have CLAUDE.md files at different levels:

your-project/
  CLAUDE.md          ← root: ecosystem-wide context
  service-a/
    CLAUDE.md        ← service-specific context
  service-b/
    CLAUDE.md        ← service-specific context

Claude Code reads both — root first, then the most specific one for the files it's working in.

5. Writing prompts that work

The quality of Claude Code's output is directly proportional to the quality of your prompt. Here's the difference:

Weak prompt

Add authentication to the app

This works, but the result will be generic. Claude Code will make decisions you'd probably make differently.

Strong prompt

Add JWT authentication to the Express backend following the existing 
pattern in src/routes/users.js. 

The middleware should:
- Verify the token from the Authorization: Bearer header
- Attach req.user with { id, username, role }
- Return 401 { error: 'Unauthorized' } if invalid
- Skip auth for POST /api/auth/login and GET /health

Add the middleware to all routes in src/routes/ except auth.js.
Do not change the existing token generation logic.

Same task. Completely different output.

Key principles

Reference specific files. "Follow the pattern in src/services/docker.js" is worth more than "follow existing patterns".

State what not to do. "Do not modify the database schema" or "do not change the auth flow" prevents unwanted side effects.

Specify the output format. If you want a specific response structure, API contract, or file layout — say so explicitly.

Ask for analysis first. For complex tasks, start with: "Read these files and tell me what you find before writing any code". This catches misunderstandings before they become wrong code.

6. Phase-based development

For large tasks, break the work into numbered phases. This is the pattern that makes Claude Code genuinely powerful for complex projects.

## PHASE 1 — Analysis (no code yet)
Read and understand:
- src/backend/server.js
- src/backend/src/routes/ (all files)
- src/frontend/src/App.jsx

Identify and report:
1. How authentication currently works
2. What routes exist and their patterns
3. Any inconsistencies or potential conflicts

Do not write any code until you've reported your findings.

## PHASE 2 — Backend changes
[detailed instructions]

## PHASE 3 — Frontend changes  
[detailed instructions]

## PHASE 4 — Tests and verification
[what to check]

Why this works:

Phase 1 forces analysis before action. You catch wrong assumptions early.
Numbered phases give Claude Code a clear structure to follow.
You can pause between phases to review.
If something goes wrong in Phase 2, Phases 3 and 4 haven't been touched.

7. Slash commands and shortcuts

Claude Code has built-in commands you can use mid-session:

/init          # Generate CLAUDE.md from your project
/clear         # Clear conversation context (start fresh)
/compact       # Summarize conversation to save context space
/cost          # Show token usage for the current session
/help          # List all available commands

The Ctrl+C behavior: pressing once interrupts the current action. Claude Code stops, tells you what it was doing, and waits. You can then redirect or continue.

The --print flag — useful for scripting:

claude --print "What does this function do?" < src/utils/parser.js

Outputs directly to stdout, no interactive session needed.

8. What Claude Code can and cannot do

It can

Read and write any file in your project
Run bash commands (builds, tests, installs, docker commands)
Fix its own errors when a build fails
Work across multiple files and services simultaneously
Remember context within a session
Follow complex multi-step instructions

It cannot

Remember anything between sessions (CLAUDE.md solves this)
Access the internet during a task
Start system processes it doesn't have permission for
Make git commits or pushes (by design — you stay in control)
Replace code review (it makes mistakes, especially on subtle logic)

The git boundary

Claude Code deliberately doesn't push to git. This is the right call. Every commit should be a human decision. Claude Code generates the code; you review, commit, and push. This keeps you in the loop on what's actually going into your repository.

9. Workflow patterns that scale

The morning brief

Start each session by telling Claude Code the current state:

Context for this session:
- We're working on the authentication module
- Last session we completed the backend JWT middleware
- Today's goal: add the login/logout UI components
- Known issue: the token refresh endpoint returns 500 intermittently
- Do not touch src/backend/auth.js — it's being refactored separately

This takes 2 minutes and saves a lot of confusion.

The reference pattern

When building something new, always point to the closest existing thing:

Create a new NotificationsPanel component.
Follow the exact structure of src/components/SettingsPanel.jsx —
same file layout, same CSS variable usage, same props pattern.
Only change the content and specific functionality.

This keeps your codebase consistent even as it grows.

The verification step

Always end complex tasks with an explicit verification instruction:

After completing the changes:
1. Run the build and confirm it succeeds
2. Check that these endpoints respond correctly: /health, /api/auth/login
3. Report any warnings in the build output

Claude Code will do this and tell you what it found.

Splitting sessions for large projects

Context has limits. For very large tasks, split into sessions:

Session 1: Backend changes → verify → commit
Session 2: Frontend changes → verify → commit
Session 3: Integration and testing → verify → commit

Each session starts fresh but CLAUDE.md provides continuity.

10. Common mistakes and how to avoid them

Vague task descriptions
The vaguer the prompt, the more decisions Claude Code makes for you. Those decisions may not match your intent. Be specific.

Skipping the analysis phase
Jumping straight to "build this" on complex tasks leads to code that doesn't fit your existing patterns. Always read first.

Not updating CLAUDE.md
Every architectural decision you make should go into CLAUDE.md. If you decide to use a specific error handling pattern, write it down. Future sessions will inherit that decision.

Letting it run too long without review
For tasks over 15-20 minutes, check in. Ask it to report what it's done so far. This catches drift early.

Not using explicit file references
Generic instructions produce generic code. Specific file references produce code that fits your project.

Treating it as infallible
It makes mistakes. Especially on:

Complex business logic
Security-sensitive code
Subtle state management bugs
Anything requiring domain knowledge you haven't documented

Review the output. Always.

Summary

Claude Code is most powerful when you treat it as a skilled developer who:

Needs good context to do good work
Benefits from explicit instructions over implicit expectations
Should be given clear scope and boundaries
Needs review on their output, not rubber-stamping

The developers who get the most out of it aren't the ones who give it the least guidance. They're the ones who invest in their CLAUDE.md, structure their prompts carefully, and review the output critically.

The ceiling on what a solo developer can ship has moved. But the floor — the minimum investment in clear thinking and good specification — hasn't.

If this was useful, I write about self-hosted tools, Docker, and AI-assisted development.

GitHub: github.com/Alvarito1983
Docker Hub: hub.docker.com/u/afraguas1983

claudecode #ai #programming #webdev #docker #devtools #opensource #productivity #softwaredevelopment

NEXUS Ecosystem: I built a modular Docker management ecosystem in my spare time

Alvarito1983 — Mon, 06 Apr 2026 17:45:45 +0000

I've been building NEXUS in my spare time for the past few months. What started as a simple Docker management panel has grown into something I'm genuinely proud of — a full ecosystem of self-hosted tools with a shared visual identity and a central control hub.

Here's where the project stands today.

What is NEXUS Ecosystem?

NEXUS is a modular ecosystem of self-hosted Docker management tools. Each tool works independently as a standalone app, but they're all designed to connect through a central hub — sharing authentication (SSO), service registry, and a unified dashboard.

The design language is what I call Dark Premium: inspired by tools like Linear and Vercel. Dark-first, precise, no unnecessary decoration.

What's already built

NEXUS (port 9090 · #00c896)
The core panel. Container management, image control, volume and network inspection, stack deployment, real-time terminal, metrics view. This is the most mature tool in the ecosystem.

Watcher (port 9091 · #F0A500)
Monitors Docker images for updates in real time. Shows available updates with digest comparison, lets you pull new versions with a progress bar directly from the UI, and tracks update history.

Pulse (port 9092 · #3b82f6)
Performance metrics per container — CPU, memory, network I/O. Clean charts, real-time via Socket.io.

NEXUS Hub (port 9095 · #534AB7)
The ecosystem control center. Handles SSO across all tools, maintains a service registry, polls each tool's health endpoint every 30 seconds, and provides a unified overview dashboard. NEXUS and Watcher are already integrated.

What I'm building right now

Security (port 9093 · #ef4444)
Visibility into exposed ports, container vulnerabilities, and attack surface across all registered hosts.

Notify (port 9094 · #8b5cf6)
Multi-channel alert system — Telegram, Discord, Webhook, Email. Triggered by ecosystem events: container down, image update available, high CPU, and more.

Both Security and Notify will live as Hub-integrated modules rather than standalone tools — because their real value is cross-host visibility, not single-host monitoring.

Tech stack

Frontend: React 18 + Vite, CSS custom properties (no Tailwind), Lucide React
Backend: Node.js + Express + Socket.io
Auth: JWT + SSO pattern between tools
Storage: SQLite / JSON per tool
Deployment: Docker, published to Docker Hub and GHCR via GitHub Actions
CI/CD: push to main → build → publish automatically

Architecture decision: standalone vs Hub-integrated

One thing I had to think carefully about: which tools make sense as standalone apps and which ones only make sense inside the Hub.

NEXUS, Watcher and Pulse work well standalone — they provide value on a single host without needing global context. Security and Notify don't. A security panel that only sees one host misses the point. An alert system that can't aggregate events across the whole ecosystem is just noise.

So the roadmap split naturally into two product lines: standalone tools (independent, :latest tags on Docker Hub) and Hub-integrated modules (centralized IdP, SSO, multi-host support).

Where to find it

GitHub: github.com/Alvarito1983
Docker Hub: hub.docker.com/u/afraguas1983

All open source. Still actively developing — if you're into self-hosting, Docker, or just building your own tools, feel free to follow along or contribute.

docker #selfhosted #opensource #react #nodejs #homelab #devtools #webdev

How Claude Code + Specialized Agents Changed My Development Workflow in 2026

Alvarito1983 — Sun, 05 Apr 2026 18:55:50 +0000

I've been using Claude Code daily for months. Here's my honest take on what actually changed — and what didn't.

It's not autocomplete. It's orchestration.

The mental shift that made everything click: I'm the architect. Claude Code is the implementation layer. Once I stopped trying to use it as a smarter Copilot and started treating it as a capable collaborator that needs clear direction, everything improved.

What it does well

Legacy refactoring — Feed it an 800-line file with no tests and it reorganizes it into coherent modules with sensible names. What used to take an afternoon takes 10 minutes.

Contextual debugging — Unlike pasting code into a chat window, Claude Code sees the entire project. When I say "this endpoint fails intermittently," it understands the middleware chain, the models, the dependencies. The diagnosis is much more precise.

Test generation — It generates edge cases I wouldn't have thought of. Projects that had 30% coverage now sit at 90%+.

Where it falls short

Architecture from scratch — If you give it total freedom on a new project, it produces something that works but that you don't fully understand. Design the structure yourself first.

Domain-specific code — Legacy proprietary systems, niche APIs. It hallucinates more here.

The agent layer changed things again

I recently installed the wshobson/agents plugin marketplace for Claude Code. It adds 182 specialized agents — Docker/Kubernetes, security scanning, CI/CD automation, distributed debugging, LLM application development.

Instead of asking generic questions, you activate the expert agent for what you need. The full-stack orchestration workflow coordinates multiple agents for a feature: backend architect → database designer → frontend developer → test automator → security auditor.

claude plugin marketplace add wshobson/agents
claude plugin install kubernetes-operations@claude-code-workflows
claude plugin install security-scanning@claude-code-workflows
claude plugin install llm-application-dev@claude-code-workflows

My current workflow

I design the architecture
Claude Code implements
I review and correct
Claude Code adds tests and documentation
Security agent audits before deploy

Real example from 2026

I'm building a self-hosted forum (React 18 + Node.js + SQLite + Docker) and a separate property tracker with WhatsApp notifications. Both built with Claude Code. The forum went from zero to a full invite-only community platform with real-time replies via Socket.io in a few sessions.

The property tracker scrapes listings, detects price drops, and sends WhatsApp messages via whatsapp-web.js — all containerized, all running on my homelab server.

Neither of these would have been practical solo projects before. Now they're weekend projects.

I also maintain NEXUS — an open source Docker management ecosystem (NEXUS, Watcher, Pulse) that I build entirely with Claude Code. What started as a simple container panel grew into a multi-host management platform with real-time metrics, image update detection, and uptime monitoring. All MIT licensed, all self-hosted.

The honest take

Claude Code doesn't replace engineering judgment. It amplifies implementation speed. If you know what you're building and why, it's extraordinary. If you don't have a clear direction, it'll confidently build the wrong thing.

The agents add genuine depth — a security agent that actually knows OWASP, a Kubernetes agent that understands production patterns. Not generic answers, specialized knowledge activated on demand.

If you're a developer with a homelab or side projects, this is worth your time.

→ NEXUS on GitHub: https://github.com/Alvarito1983/NEXUS

Why I Built My Own Docker Dashboard Instead of Using Portainer

Alvarito1983 — Sat, 04 Apr 2026 17:22:01 +0000

If you've ever managed more than a handful of Docker containers, you've probably heard of Portainer. It's the go-to answer whenever someone asks "how do I manage my Docker setup with a UI?" — and for good reason. It works, it's free, and it covers a lot of ground.
I used it too. For a while, it was good enough.
But "good enough" has a way of not staying good enough.

What Portainer Does Well
Let's be fair. Portainer is genuinely impressive for what it is — a full-featured, enterprise-ready container management platform. You get:

A visual interface for containers, images, networks, and volumes
Stack management with Docker Compose support
Multi-environment support
Role-based access control
An active community and solid documentation

For teams or complex enterprise setups, it's hard to argue against it. But I wasn't running a team. I was running a homelab.

Where It Started Feeling Wrong
The more I used Portainer, the more I felt like I was using a tool built for someone else's workflow.
It's a big application. The UI has a lot going on — menus, submenus, settings buried three levels deep. Every time I just wanted to restart a container or check what image a service was running, I was navigating through more interface than I needed.
And the visual design — while functional — never felt like mine. I know that sounds like a minor thing. But when you spend time every day in a tool, the aesthetic matters more than people admit.
I also run Docker on Windows with a specific multi-host setup, and getting Portainer to behave exactly the way I wanted in that context required more configuration than felt reasonable for a personal project.
I wasn't looking for less power. I was looking for the right power, in the right shape.

The Moment I Decided to Build Something
I remember the exact moment I stopped tweaking Portainer and started thinking about alternatives. I was trying to set up a clean view of just the containers I cared about, with the metrics I actually used, in a layout that made sense to me — and I realized I was fighting the tool instead of using it.
So I asked myself: how hard would it actually be to build what I want?
I already knew React and Node.js. I had a clear picture of what I needed — a clean, minimal dashboard that showed me exactly what I wanted and nothing else, with a UI I was proud of looking at.
That became NEXUS.

What NEXUS Does Differently
NEXUS isn't trying to replace Portainer for enterprise use cases. It's built around a different philosophy: clarity over completeness.
The core features I focused on:
Container management — start, stop, restart, remove. Real-time status. No noise around the edges.
Image management — pull, inspect, remove. Watcher (part of the ecosystem) handles automated update detection with Socket.io-powered real-time progress and image deduplication.
Monitoring — Pulse gives me per-container CPU, memory, and network stats in a clean dark interface without having to navigate anywhere.
Multi-host support — a lightweight Agent runs on remote hosts and reports back to the central NEXUS instance. No heavy infrastructure needed.
Design system I actually like — dark premium UI inspired by Linear and Vercel aesthetics. CSS custom properties, Inter + JetBrains Mono typography, layered dark backgrounds. It looks exactly how I want it to look.
Everything runs in Docker. The whole stack is up with a single docker compose up -d.

Is Portainer Bad? No.
I want to be clear: this isn't a takedown of Portainer. It's a great tool and the right choice for a lot of people — especially if you need enterprise features, team access control, or you're managing complex multi-environment setups professionally.
But there's real value in building something tailored to your exact needs. Not just the functional value — the learning you get from it, the ownership you feel over the tool, and the fact that you can extend it in any direction you want without waiting for a feature request to be picked up.
If you're a developer or sysadmin with a homelab and some free weekends, I'd genuinely recommend trying to build your own tooling at least once. You'll learn more than you expect.

Where NEXUS Is Now
NEXUS is open source (MIT license) and actively developed. Current versions: NEXUS v1.5.6, Watcher v1.3.0, Pulse v1.2.0.
The roadmap includes standalone Security and Notify modules, and a Hub integration layer for centralized multi-tool management with SSO.
If you're curious, you can find it on GitHub and Docker Hub under Alvarito1983 / afraguas1983.
Feedback, issues, and stars are always welcome. 🙂

I built a self-hosted Docker management ecosystem — NEXUS, Watcher and Pulse (open source, MIT)

Alvarito1983 — Thu, 02 Apr 2026 17:41:44 +0000

A few months ago I got tired of Portainer.

Not because it's a bad tool — it's excellent at what it does. But for managing my homelab it felt like driving a truck to buy groceries. Too much complexity, too many dependencies, too much noise for what I actually needed.

So I built my own.

What started as a simple panel to see my containers turned into a full ecosystem of tools for managing Docker infrastructure. This is the story of what I built, every technical decision I made, and where it's going.

NEXUS — Docker Manager

NEXUS is a self-hosted Docker management panel. No external database, no cloud dependency. One docker compose up and you're running at http://localhost:9090.

Core features:

Real-time metrics — CPU & RAM per container with live sparkline history
Stack view — containers grouped by docker-compose project
Integrated terminal — docker exec directly from the browser, no SSH needed
Multi-host — manage multiple Docker servers from one panel
Full management — images, networks, volumes, stacks with built-in YAML editor
Crash alerts — Telegram notification when a container stops unexpectedly
Roles — Admin and Viewer, control who can do what
PWA — installable on desktop and mobile

But the most important technical decision wasn't any of those features. It was how to solve multi-host without compromising security.

The agent architecture

The classic multi-host Docker problem: to manage a remote server you need access to the Docker socket. And the Docker socket is basically root access to the system.

The common solution is to expose the socket over TCP. That's a massive security hole — you're putting root access on the network.

NEXUS solves it differently:

Browser → NEXUS (:9090)
              ↓
         NEXUS Agent (remote host)
              ↓
         Docker socket (never leaves the host)

The agent is a lightweight process running on each remote host. It wraps the socket in its own authenticated API and only exposes the endpoints NEXUS needs. The socket never leaves the host. Communication between NEXUS and the agent uses JWT with 24h expiry.

Result: multi-host management without compromising system security.

# Install NEXUS
curl -O https://raw.githubusercontent.com/Alvarito1983/NEXUS/main/docker-compose.yml
cp .env.example .env
docker compose up -d
# → http://localhost:9090

NEXUS Watcher — Image Update Monitor

Once the panel is running, another problem surfaces: how do I know when updates are available for my images?

The naive solution is tag comparison. If you have nginx:latest and a newer version exists, the tag will have changed. Problem: many images use stable tags that don't change (latest, stable, main) even when the image content has changed.

NEXUS Watcher solves this with manifest digest comparison.

Why digests instead of tags

Every Docker image has a digest — a SHA256 hash of the manifest that describes the image. When a publisher updates an image, the digest changes even if the tag stays the same.

Watcher's flow:

Gets the local digest of each installed image
Queries the registry (Docker Hub or GHCR) for the current remote digest
Compares both — if they differ, there's an update available

For Docker Hub, this requires getting an OAuth token from auth.docker.io first, then querying registry-1.docker.io/v2/{repo}/manifests/{tag} and extracting the docker-content-digest header.

This method detects real updates, not just tag changes.

Real-time update feedback

One issue with earlier versions: you clicked "Update" and had no idea what was happening. Is it downloading? Did it finish? Did it fail?

Dockerode (the Docker wrapper for Node.js) emits progress events during a pull — layer by layer, with percentages. The current version of Watcher exposes those events via Socket.io to the frontend, showing a real-time progress bar with per-layer detail.

It also shows:

Short digest of the new version (first 12 chars of SHA256)
Affected containers — which containers will be recreated
Update history
Digest-based rollback — one click to go back if something breaks

# Install Watcher
curl -O https://raw.githubusercontent.com/Alvarito1983/nexus-watcher/main/docker-compose.yml
cp .env.example .env
docker compose up -d
# → http://localhost:9091

NEXUS Pulse — Uptime & Health Monitor

Once containers are managed and images are updated, one question remains: are they actually working?

NEXUS Pulse is a self-hosted uptime monitor. It monitors:

Docker containers — Running/Stopped/Other state
Web — HTTP/HTTPS with SSL certificate verification and expiry date
TCP — port availability
DNS — domain resolution
Database — connection health check
API — endpoint response validation

Each monitor has a 30-check history bar — the last 30 results represented as colored vertical bars (green = up, red = down, amber = pending). One glance and you know the recent history of any service.

Alerts go via Telegram with status, response time and timestamp.

# Install Pulse
curl -O https://raw.githubusercontent.com/Alvarito1983/nexus-pulse/main/docker-compose.yml
cp .env.example .env
docker compose up -d
# → http://localhost:9092

The technical stack

All tools share the same architecture:

Layer	Tech
Backend	Node.js + Express + Socket.io + Dockerode
Frontend	React 18 + Vite + Lucide React
Auth	JWT + scrypt
Storage	JSON file (no database)
CI/CD	GitHub Actions → Docker Hub + GHCR
License	MIT

Why JSON instead of a database

Deliberate decision. For the use case of these tools (homelab, small teams) a database is overkill and adds a dependency that complicates deployment. The JSON file persists across restarts and is fast enough for the data volume these tools handle.

The design system

The frontend uses a custom Dark Premium design system — inspired by tools like Linear and Vercel. Each tool has its own accent color (green for NEXUS, amber for Watcher, blue for Pulse) but they share the same visual foundation: Inter + JetBrains Mono typography, layered dark backgrounds (#0a0a0f → #111118 → #1a1a24), staggered entry animations.

The goal was that each tool feels like part of the same family while working completely standalone.

What's coming

Each tool works independently but they're designed to integrate:

NEXUS Security (in development)
CVE analysis on installed images, SSL certificate auditing, unnecessary exposed port detection. The goal is security visibility without depending on cloud services.

NEXUS Notify
Unified alert routing. Instead of configuring Telegram in each tool separately, Notify acts as a notification hub — receives events from all tools and distributes them according to configurable rules.

NEXUS Hub
The central panel. SSO for the entire ecosystem — one login, one view of all hosts and all tools. Hub also acts as a shared host directory: add a host once and all tools see it.

Try it

All three tools are MIT licensed, fully open source, and self-contained.

🔗 NEXUS: https://github.com/Alvarito1983/NEXUS
🔗 Watcher: https://github.com/Alvarito1983/nexus-watcher
🔗 Pulse: https://github.com/Alvarito1983/nexus-pulse
🌐 Web: https://alvarito1983.github.io/nexus-web/

Happy to answer questions about the architecture, the digest-based detection approach, or the agent security model in the comments.

Tags: docker, selfhosted, opensource, node, react, homelab, devops