DEV Community: Adrien Fischer

From Prompts to Pipelines: How I Use Agentic Coding as an Engineering Workflow

Adrien Fischer — Wed, 08 Jul 2026 21:25:00 +0000

I am interested in agentic coding for the same reason I care about good engineering process in general: I want work to move forward in a way that is inspectable, repeatable, and resilient once the task gets messy.

A lot of AI-assisted coding still feels like improvisation. You ask for something, get a result, adjust the prompt, try again, and hope the useful reasoning is still somewhere in the scrollback. That can work for tiny edits. It gets much less convincing when the task starts touching architecture, tests, review, or pull requests.

What I want instead is a workflow where the model helps me think and execute, but inside a structure I can inspect afterwards. I want artifacts, gates, and something I can resume tomorrow without reconstructing the entire mental state from memory.

That is why I use po8rewq/agentic-skills.

It gives me a practical way to do agentic coding as an engineering workflow rather than as a long sequence of chat turns. A task moves through requirements, architecture, implementation, checks, review, and pull request creation. Each stage leaves something I can read, verify, and challenge.

What makes this interesting to me

The interesting part is not just that there is a CLI. Plenty of tools have a CLI.

What matters to me is that it turns AI-assisted coding into a staged system:

requirements force the task to become explicit
architecture makes risks visible before code is written
implementation happens against a plan instead of against a vague prompt
checks and review happen as part of the flow, not as an afterthought
runs are resumable, so interruptions do not destroy context

That changes the feel of the work quite a bit. Instead of asking "what should I prompt next?", I am usually asking "what stage is this task in, and what should exist before I move on?"

Where this really clicked for me was when I noticed I was spending less energy trying to preserve context in my head and more energy evaluating actual outputs.

What the repository actually provides

The repository itself is fairly small and opinionated in a good way:

agentic/ contains the Python package and CLI entry points
pipelines/ contains definitions such as default.yaml, cheap.yaml, and production.yaml
skills/ contains the Markdown instructions used by each stage
templates/ and scripts/ contain setup helpers

I like that the shared repository stays centralized while each project keeps only the parts that should be project-specific.

In the target repository, I usually only need:

agentic.yaml
.ai/skills/
optionally .ai/context/
optionally .ai/memory/

That separation is one of the reasons the workflow feels sustainable. The orchestration logic lives in one place, while each repository keeps its own commands, context, and operating rules.

What surprised me is how much this small separation changes the feel of the system. It stops feeling like a clever demo and starts feeling like something I can keep around.

How the pipeline is driven

The config is not just setup. It is the part that tells the pipeline how to behave: which provider to use, which commands to run, when to ask for approval, what context to load, and how the task should progress from one stage to the next.

A very small agentic.yaml can already show the idea:

project:
  name: my-api
  default_branch: main
providers:
  default: claude-code
  available:
    claude-code: {command: claude}
forge:
  provider: github
  create_pr: true
commands:
  install: pnpm install
  lint: pnpm lint
  typecheck: pnpm typecheck
  test: pnpm test
  build: pnpm build

That is obviously not a full production config, but it already makes the model operate inside a real engineering boundary. It knows which provider to call, which repo commands count as checks, what the main branch is, and whether it should prepare a PR at the end.

From there I usually add the pieces that make the workflow more serious:

model aliases by stage
gating and risk-routing rules
context and memory paths
project-specific command overrides

Once that file exists, I stop thinking in terms of isolated prompts and start thinking in terms of pipeline behavior.

The part I did not expect is that a boring config file would do so much work. It quietly turns "use an AI assistant here" into an operating model with boundaries.

How I set it up

The setup is intentionally boring, which is part of the appeal.

I install the shared package from po8rewq/agentic-skills:

cd /path/to/agentic-skills
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install --upgrade pip setuptools
python3 -m pip install -e .

That gives me three commands:

run-pipeline
validate-agentic-config
install-agentic-skills

In the target project, I copy the example config:

cp /path/to/agentic-skills/agentic.example.yaml /path/to/project/agentic.yaml

Then I install the shared skills:

install-agentic-skills --source /path/to/agentic-skills/skills .ai/skills

For starter repo context and memory files:

install-agentic-skills --with-context --with-memory .ai/skills

At that point, the workflow is ready to try on a real task.

What it looks like on a small task

The easiest way to understand the workflow is to run a tiny change through it.

Take a small but real task like: "Add audit logging to endpoint X."

Before I worked this way, that kind of task usually turned into a loose sequence of prompts and manual checks. I would explain the endpoint, ask for a plan, ask for an implementation, remember to think about logging format, wonder whether I had missed a migration or config update, run tests manually, and then do a separate cleanup pass before opening a PR.

With the pipeline, the same task becomes much more structured:

Before	With the pipeline
I describe the task in chat and keep refining the prompt.	I start with a task and let the pipeline create explicit requirements.
Architecture concerns stay in my head unless I stop and write them down.	Architecture is a stage, so affected modules, risks, and planned files get written down early.
Implementation can drift because the prompt keeps changing.	Implementation happens against the requirements and design artifacts.
Checks are easy to postpone or do inconsistently.	Lint, typecheck, test, and build are part of the flow.
Review often happens informally after the code already feels "done."	Review is a first-class stage with artifacts and follow-up fixes.
If I get interrupted, I have to reconstruct context from chat history and git diff.	I can resume from the saved run artifacts under `.ai/runs/`.

That is the practical difference I care about most. The pipeline does not just help me write code faster. It keeps the task legible while it moves.

On a task like "Add audit logging to endpoint X", that usually means I get something concrete from each stage:

the requirements stage produces a short spec that clarifies which endpoint is in scope, what event should be logged, what fields need to be captured, and what does not need to change
the architecture stage identifies the affected modules, calls out risks such as logging sensitive data or introducing duplicate events, and proposes where the logging should live
the implementation stage works against those artifacts instead of inventing the shape of the change on the fly
the review stage can flag things that are easy to miss in a chat-only flow, like missing test coverage, noisy log payloads, or logging at the wrong boundary

That is the part I find reassuring. Even on a small task, the workflow leaves behind enough structure that I can inspect the reasoning instead of just trusting the final diff.

I usually start with a dry run:

run-pipeline --dry-run --skip-approval --task "Preview the workflow"

That gives me a quick read on the configuration, the stage order, and the prompts without committing to actual work.

Then I try something intentionally small:

run-pipeline --pipeline cheap --task "Fix a typo in the README"

I like using a trivial task first because it teaches the workflow without forcing me to debug a complex change and a new process at the same time.

Every run is stored under .ai/runs/<timestamp>-<task>/. That directory is one of the biggest reasons I like this approach. It keeps the merged config snapshot, prompts, provider outputs, command results, state, and pull request context.

If a run stops halfway through, I can resume it:

run-pipeline --resume .ai/runs/2026-07-07-add-audit-logging

That sounds like a small detail, but it changes the experience a lot. Interruptions stop being destructive.

That was another moment where it clicked for me. Resumability sounds like a convenience until you use it on a real week with meetings, interruptions, and half-finished thoughts.

Why the staged flow matters

The default pipeline is intentionally linear:

Requirements
Architecture
Implementation
Checks
Review
Fix review findings
Final checks
Pull request

That linearity is not a limitation. It is what gives the workflow its shape.

More importantly, each stage leaves behind a different kind of output:

requirements produce a task spec: what needs to change, what constraints matter, and what is explicitly out of scope
architecture produces design decisions: how the change should be approached, which modules are affected, and what risks need attention
implementation produces the actual code changes guided by those earlier artifacts
checks produce concrete command output from lint, typecheck, test, and build
review produces issues, findings, and suggested fixes instead of a vague sense that the diff "looks fine"

Later stages only happen if earlier stages are in a good enough state. That is what makes the pipeline feel real to me. It is not just a sequence of labels. It is a sequence of concrete outputs.

That is the part I find compelling. I do not need to invent a new ritual every time I want to use AI on a real software task.

When I reach for it

I reach for this style of agentic coding when I want a task to be:

repeatable
inspectable
auditable
resumable
safe enough to route through staged checks

It is especially useful when a change benefits from a requirements pass before implementation, or when I want review and PR creation to happen inside the same flow instead of as separate manual cleanup steps.

In practice, I think this works best for solo developers or small teams doing backend, infrastructure, platform, or full-stack work where a task touches multiple concerns at once: code, tests, configuration, and review. It is much less compelling for quick edits or highly visual exploratory work where the overhead is larger than the payoff.

Where this can break down

This workflow is not free.

For trivial tasks, the overhead can be higher than the value. It also requires discipline: if the config, skills, or repo context drift away from reality, the pipeline becomes less useful very quickly.

Debugging pipeline behavior can also be its own kind of work. When a stage produces something weak, the problem might be the prompt, the config, the context files, the model choice, or the task itself. That is more structured than random prompt iteration, but it is still a system you have to maintain.

It is also not the best fit for highly exploratory work. If I am still figuring out what I even want to build, a staged pipeline can feel premature. I find it most useful once a task is real enough to benefit from explicit requirements, checks, and review.

The main lesson

The main thing I have learned is that agentic coding gets more useful when it stops feeling like magic.

I do not want an opaque assistant that sometimes writes code and sometimes loses the plot. I want a system that helps with execution while leaving behind enough structure that I can understand what happened, challenge it, and keep moving.

That is the shift that matters most to me. I no longer think in prompts. I think in stages, artifacts, and decisions.

Designing Single-Purpose Agents Instead of One Big Automation Script

Adrien Fischer — Tue, 23 Jun 2026 20:30:00 +0000

"Agent" has become one of those words that means everything and nothing this year. Before it was a hype term, I'd already ended up with a small flock of them in my homelab. Not because I was chasing a trend, but because I kept hitting the same wall every time I tried to write One Big Script: it grew a dozen unrelated responsibilities, and a bug in one of them risked taking down all of them.

In short: I prefer many small, single-purpose automation agents over one large script because each agent has a narrow job, a clear output contract, and an independent schedule. The system stays maintainable because agents communicate through JSON artifacts, one notification channel, and one dashboard.

So instead, every recurring chore in my homelab is its own small, independently-scheduled program. There turned out to be more of them than I expected once I actually sat down and counted.

A note for muggles: the repo behind all this is named hogwarts, and every agent gets sorted to match. Once you start naming services after wizards, it turns out you owe each one an in-character job description, whether it asked for one or not.

The standing watch. Four observers poll continuously and report into one correlator every five minutes. This is the layer that exists so I find out about a problem before it becomes a 3am page instead of after:

Argus Filch watches running Docker containers for restart loops, failed healthchecks, and containers that just quietly vanish.
Astronomy Tower polls Prometheus for firing alerts, down scrape targets, and recording rules that stopped working without telling anyone.
Marauder's Map scans the UniFi network for offline devices, WAN failover events, and firewall rules that drifted open.
Mad-Eye's Watch tracks TLS certificate expiry across configured endpoints. Constant vigilance: a warning at 30 days, a critical at 7.
The Headmaster is the one role on this list that isn't single-purpose by design. Its entire job is reading what the other four decided was worth reporting and correlating that into one status, surfaced as an incident only when it's actually worth one.

The daily and weekly chores. These run on their own cron schedules and never talk to each other directly:

Molly's Cupboard reviews the Home Assistant entity list weekly: unavailable entities, missing or duplicate names, disabled automations. (Molly Weasley: keeps the household running, judges your clutter lovingly.)
Rita's Desk is the RSS morning digest: feeds in, previous day's articles out, ranked against persistent tag scores I vote on. Deterministic by design, no LLM in the loop. (Never met a headline she wouldn't print, but at least she always sources it.)
Kreacher's Kitchen plans the week's meals from my recipe library and a couple of trusted cooking sites. (Grumbles the entire time, still gets dinner on the table.)
The Library picks a tech topic every night, gathers sources, and writes a 5-minute digest plus a 15-20 minute deep dive. (Lives in the package manifest as research-digest, but it spends every night in the Restricted Section, so the Library it is.)
Madam Pince's Catalogue lists every running container and cross-checks it against the service directories in the infra repo, flagging any container that has no matching documentation. (A very particular librarian: every book gets catalogued, or it gets confiscated.)
Dobby's Rounds is the homelab's free elf: weekly housekeeping that prunes old snapshots, reports, and state files before they pile up.
O.W.L.s is the daily infrastructure audit: config drift, open ports, compliance. Read-only and deliberately paranoid about it. (Ordinary Wizarding Level exams: thorough, exhausting, and not interested in your excuses.)
Auror Office is the daily cross-domain security digest, correlating O.W.L.s' findings with auth logs, Docker posture, and the network observers above into one report. (No badge, but it does go looking for dark wizards. I've written about how this one and O.W.L.s work together in more detail elsewhere.)
...and others, including media management, recommendations, and a handful more in the same spirit. Small enough that listing every one of them would be its own blog post.

Thirteen-plus names, just as many jobs. Outside of the two correlators built specifically to know about everyone else — the Headmaster and the Auror Office — not one of them needs to care that the rest exist.

The three conventions that make this work

None of these agents are individually clever. What makes the flock manageable is that they all obey the same three small contracts:

1. One artifact format. Every agent writes its result as JSON (and often a companion Markdown note) to its own outbox/latest/ path. A "latest" pointer plus a timestamped archive, every time. No agent reads another agent's outbox directly. If something needs cross-referencing, that's a different, explicitly-correlating agent's job, not an implicit dependency.

2. One notification channel. Every agent that needs to tell me something pushes through the same ntfy topic convention, with a deep link back into wherever the full detail lives. I don't maintain five different alerting integrations; I maintain one, and every agent is a thin client of it.

3. One aggregation point. A single dashboard reads everyone's outbox/latest/ and renders it. It doesn't collect anything itself. It has no Docker access, no Home Assistant credentials, no API keys. It's a pure read layer over JSON files other things produced. That's the only place in the whole system that's allowed to know all the agents exist.

That's the entire integration surface. Three conventions, and I can add a sixth agent tomorrow without touching the other five.

Why decompose instead of consolidate

The obvious objection: isn't five small things more to maintain than one big thing? In my experience, no. For the same reason a set of small services usually beats a monolith at work.

A bug in Peeves' Trakt pagination cannot break Molly's Home Assistant checks, because they don't share a process, a deploy, or a schedule. I can test each one in complete isolation with a fixture file instead of live credentials. I can hand any single agent's directory to a contributor - human or an AI coding agent - and they have everything they need to understand and change it, without first having to load the other four into their head. And when I retire one (Peeves only matters because I still have a media server; that won't be true forever), deleting it is deleting a directory, not untangling a shared module.

This is the same lesson as service boundaries and team topologies at any reasonably-sized engineering org: the interface between components should be small, explicit, and boring, and almost all of the design effort should go into keeping it that way. Not into making any individual component clever. The cleverness, if there is any, belongs inside one agent's narrow walls, where it can't leak.

The boring plumbing is the point

None of the five agents above is doing anything technically hard. RSS parsing, a REST API client, a cron job - this is all stuff any of us could write in an afternoon. The actual design work was deciding, up front, that "outbox JSON + one notification channel + one dashboard" would be the entire contract between them, and then refusing to let any agent reach around it.

That discipline is cheap when you only have one agent. It's the only thing that keeps five (or fifteen) from turning back into the One Big Script I was trying to avoid in the first place.

My homelab stack in 2026: what runs, why, and how it all connects

Adrien Fischer — Sun, 21 Jun 2026 04:15:00 +0000

I'm not going to make the case for self-hosting here. If you're reading this, you already get it. What I want to do instead is be honest about what I actually run, why I made the specific choices I made, and - more interestingly - how the pieces talk to each other in ways that weren't always planned from the start.

The stack runs across four machines. The bulk of Docker workloads are split between a Mac Mini and an Ubuntu mini PC. Network infrastructure - Traefik and CoreDNS - runs on a Raspberry Pi 4, which also handles the NUT server for UPS management; keeping the network layer on its own always-on hardware means a container crash elsewhere doesn't take down routing or DNS. Home Assistant runs on a Raspberry Pi 5 with the Hailo 8 AI HAT. Frigate runs alongside it as a Home Assistant add-on, which is what gives it direct access to the Hailo 8 for hardware-accelerated camera object detection - no GPU needed in the main machines for that workload.

The mental model that makes sense of the whole thing: everything gets served through Traefik, everything ships metrics to Prometheus, and Ntfy acts as the notification bus that ties async events together. Most of the rest are applications that plug into those three rails.

Category	Tools
Network	Tailscale, Traefik, CoreDNS
Dev & CI/CD	Gitea, GitHub, Woodpecker CI, Docker Registry, WUD
AI	Ollama, OpenWebUI
Search	SearXNG
Documents	Paperless-NGX, Paperless-AI
Passwords	Vaultwarden
Monitoring & management	Prometheus, Portainer, Homer
Notifications & sharing	Ntfy, Pairdrop
Home automation	Home Assistant, Frigate

The foundation

Traefik

Everything HTTP goes through Traefik. It's the reverse proxy in front of every Docker-hosted service, and the main reason I chose it over Nginx or Caddy is Docker-native autodiscovery. When I bring up a new container with the right labels, it appears behind a subdomain with automatic TLS, no config file reload required. That removes enough friction that I'm less tempted to leave things running unproxied on bare ports.

Traefik handles Let's Encrypt certificate issuance and renewal. Services that aren't on the public internet use a DNS-01 challenge, so they get valid certs without being exposed to the web. The rest of the stack is effectively Traefik labels plus container configs all the way down.

Tailscale

Tailscale is how every machine in the stack is reachable from outside the local network. All four machines are on the same Tailnet, which means I can reach any service from anywhere without opening ports or maintaining a VPN server.

Tailscale isn't fully self-hosted — the coordination server is Tailscale's. The traffic itself is peer-to-peer and never leaves the devices, but the key exchange goes through their infrastructure. For a homelab, that trade-off is easy to accept; for stricter control, Headscale is the self-hosted alternative.

CoreDNS

CoreDNS handles local name resolution. All internal subdomains resolve to the local machine without ever leaving the network, which means Traefik's label-based routing is actually usable on every device without editing hosts files or relying on split-horizon DNS from the router. CoreDNS sits upstream of the system resolver and forwards anything it doesn't own to the public DNS of choice. It's invisible when it works, which is most of the time.

Dev & CI/CD: the pipeline

This is where the most deliberate architecture lives, because I wanted something that felt like a real deployment pipeline rather than manually building and copying images around.

Gitea

Gitea is where all private repositories live: infra configs, personal projects, anything I don't want on a third-party server. Public projects still go to GitHub because that's where the audience is, but a number of those GitHub repositories are mirrored back to Gitea as a local backup. The split is simple: Gitea for control and resilience, GitHub for reach.

Woodpecker CI

Woodpecker CI is the pipeline runner, hooked directly into Gitea webhooks. Push to a branch, a pipeline runs. The config lives as a .woodpecker.yml at the repo root, which means pipeline definitions are versioned alongside the code. Woodpecker builds Docker images and pushes them to a local registry on the same host.

Local Docker registry

A plain Docker registry container, served behind Traefik. Woodpecker pushes here; docker compose pulls from here. Keeping images local means builds are fast, no rate limits, and nothing depends on an external registry being up. Not sophisticated. Exactly as much complexity as needed.

WUD - What's Up Docker

WUD watches running containers and detects when upstream image versions are newer than what's deployed. It doesn't auto-update by itself in my setup, I use it as a detection layer. When it spots a new version, it fires a notification through Ntfy, which I'll get to shortly. The result is that upstream updates surface as notifications I can act on rather than surprises I discover when something breaks.

Local AI: Ollama + OpenWebUI

I run Ollama for local model inference. The main draws are the obvious ones: no data leaves the machine, no per-token cost, models available offline. Local models cover summarization, document classification, and general Q&A; tasks where a smaller model is good enough and keeping data local matters.

Code assistance is the clear exception: small models aren't reliable enough there, so that goes to cloud APIs - Claude or Codex depending on the task. OpenWebUI makes the split seamless: it sits in front of Ollama but also accepts API keys for cloud providers. In practice I open one interface and pick a model from a dropdown rather than switching tools. Local by default, cloud when it's actually worth it.

OpenWebUI also connects to SearXNG as a search tool, which means it can pull current information without phoning home to a commercial search provider.

Search: SearXNG

SearXNG is my default search engine on all devices. It's a meta-search engine. It queries multiple sources and aggregates results. But the key property is that queries don't get tied to an account or used to build a profile. Results are good enough for 95% of searches, and for the other 5% I have a single click to fall back to whatever source I want.

The setup is minimal: one container behind Traefik, set as the default search engine in the browser. It's one of those things that took twenty minutes to deploy and I've never thought about since.

Documents: Paperless-NGX + Paperless-AI

Paperless-NGX handles all document management. Scan or drop a PDF into the inbox, it gets OCR'd, indexed, and stored. The tagging and correspondent system means I can find anything in seconds rather than digging through a folder hierarchy.

On top of that I run Paperless-AI, which hooks into the Paperless-NGX API and uses a local Ollama model to automatically suggest tags, correspondents, titles (and various other custom properties) as documents come in. This closes a loop with the AI section: Ollama isn't just a chat model, it's doing practical classification work for real files. The whole thing runs locally, so no document content touches an external service.

Password management: Vaultwarden

Vaultwarden is a self-hosted Bitwarden-compatible server. All credentials live locally, sync across devices through the standard Bitwarden clients, and never touch a third-party server. It's one of those services where the self-hosted case is unusually strong: the upstream Bitwarden clients are excellent, Vaultwarden is a drop-in replacement, and keeping your password vault on your own hardware removes a meaningful point of trust.

A password vault is the one thing you cannot lose and cannot recover from a partial backup. I wrote a dedicated post about the backup architecture covering how I handle this specifically for Vaultwarden.

Monitoring & management

Prometheus

Prometheus scrapes metrics from the stack. Node exporter covers the host, cAdvisor covers containers, and individual services expose their own endpoints where supported. The main value isn't dashboards (though those exist) - it's having a queryable record of system state over time, and a place to hook alerts when something drifts.

Portainer

Portainer is the visual management layer. I use it for quick container inspection, pulling logs, and managing stacks without SSHing in every time. It doesn't replace Prometheus, they have different jobs. Prometheus tells me what happened and when; Portainer tells me what's running right now and lets me poke at it.

Homer

Homer is a static dashboard - a single page with links to every service, configured via a YAML file. It's the least technical piece in the stack and the one my family actually uses. Rather than memorizing subdomains or digging through bookmarks, everyone has Homer as a home page: a clean grid of icons that opens whatever they need. The split between Portainer and Homer is intentional - Portainer is for me, Homer is for everyone else.

Communication & file sharing

Ntfy

Ntfy is the thread that ties the whole async event model together. It's a self-hosted push notification server. HTTP POST to a topic, and every subscribed client gets a notification. Woodpecker sends build results here. WUD sends image update alerts here. Home Assistant sends automation notifications here. Having one place where things send notifications means I can manage subscriptions in one app and stop checking dashboards compulsively.

The pattern is simple enough that anything can use it: if a script or service needs to tell me something happened, it makes an HTTP request. No SDK, no auth complexity, just a POST.

Pairdrop

Pairdrop is AirDrop for the local network, any device on the LAN can discover others and transfer files peer-to-peer through the browser. No account, no cloud relay, no app install. I use it constantly for moving files between phone, laptop, and desktop without thinking about it.

Home automation: Home Assistant

Home Assistant is the one thing in the stack that runs on bare OS rather than Docker. It's Home Assistant OS on a dedicated Raspberry Pi 5, which is a deliberate choice: the add-on ecosystem, hardware device support, and the supervisor layer all work better outside a container. Trying to run it in Docker introduced enough friction with USB devices and networking that the clean answer was to give it its own machine.

Frigate runs as a Home Assistant add-on rather than a standalone container, and that placement matters: it gives Frigate direct access to the Hailo 8 AI HAT on the Pi 5 for hardware-accelerated object detection on camera streams. Running it as an add-on keeps the integration tight and avoids the networking gymnastics that come with trying to expose a hardware accelerator across container boundaries.

It integrates back into the rest of the stack through Ntfy, automations that need to notify me fire an HTTP call to the same notification server everything else uses. One less thing to configure separately.

What's next

One thing I'm actively removing is n8n. On paper it's a great fit — nice UI, trivial to set up, an enormous library of nodes. In practice, for the automations I actually run, it's massively oversized. A tool that big has a way of becoming its own maintenance surface, and when I look at what I'm using it for, most of it is simple enough to replace with a script and an HTTP call to Ntfy. Sometimes the right answer is less, not more.

The stack has been stable enough that I've been iterating on individual services rather than adding new ones. The pieces that took the most time to get right were the CI/CD pipeline (getting Woodpecker, the local registry, and WUD to work as a coherent unit) and Paperless-AI (tuning the prompts so document classification is actually useful rather than just technically running).

If any of this is useful as a starting point, most of these services have reasonable official documentation and active communities. The architecture isn't novel, it's mostly standard self-hosting patterns assembled with some thought about how the parts should talk to each other.

Running a Personal SOC: Bringing Production Security Practices Home

Adrien Fischer — Fri, 19 Jun 2026 14:39:00 +0000

At work, nobody questions why we have logging, alerting, and a daily look at what changed overnight. At home, the same network runs a NAS, a media stack, Home Assistant, and a handful of containers. And for years my only "security monitoring" was noticing something was broken.

So I built myself a small, read-only security operations setup for the homelab: a daily audit script and a cross-domain digest agent that correlates it with everything else running on the network. Nothing here is novel security research. The interesting part is which production habits turned out to be worth carrying home, and which ones I deliberately left at the office.

Two layers, not one

The setup is split into two pieces with different jobs.

The daily audit is the boring, deterministic layer. Once a day it collects, locally and read-only:

listening sockets, flagging anything bound to a wildcard interface
Docker/container posture: privileged containers, dangerous bind mounts, host network mode, dangerous capabilities
systemd service drift against an expected allowlist
a local secrets/config hygiene scan (path, line, and pattern only - never the matched value)
cached apt list --upgradable, optionally enriched with a trivy fs scan
whether the monitoring artifacts and timers it depends on are actually present

It writes a deterministic Markdown digest and a JSON report to a local outbox. That's it. No remediation, no service restarts, no firewall changes. The rule I gave it was "assume breach, trust no single signal, change nothing during observation."

The SOC agent is the correlation layer on top. It runs once a day and pulls together SSH auth logs (brute-force detection, unexpected successful logins, elevated sudo activity), Docker security posture, UniFi network signals (unknown MAC addresses, active IPS/DPI/flood/scan/rogue alarms), and re-surfaces anything security-relevant the daily audit already found. Everything gets a severity from ok up through critical, and the result is written as an Obsidian note with YAML frontmatter. So a year of these becomes a searchable, taggable incident timeline instead of a folder of text files nobody opens.

Where the LLM fits - and where it doesn't

Both agents can optionally hand their findings to a local Ollama model to write a short narrative summary on top of the facts. This is the part I was most careful about, because it's the part most people get backwards.

The model never sees raw logs, full inventories, or matched secrets. It only compact finding titles, IDs, severities, and evidence keys. It doesn't decide what's a finding; the deterministic analyzers do that. And if Ollama is unreachable or returns something unusable, the deterministic digest ships as-is. The LLM is a narrator, never the source of truth.

That's the same boundary I'd want on a production alerting pipeline: detection logic stays deterministic and testable, and generative summarization sits strictly downstream of it, never upstream.

The part that's just operational discipline

A few choices here have nothing to do with security theory and everything to do with habits from running things in production:

Output paths are permissioned, not just "private by convention." Reports get 0600, runtime directories 0700.
Stale data is treated as a finding, not silently trusted. Upstream reports older than a configured threshold are flagged rather than quietly re-surfaced as current.
Notifications are a tap-through, not the whole story. A push notification carries the headline and a link into the actual note - useful at a glance, but the record of truth lives in the note, not in a chat history that scrolls away.
Everything is replayable offline. Both agents accept a fixture file in place of live collection, so I can test a new analyzer rule against a known input before it ever touches my real network.

What it actually buys me

Mostly, it buys me the same thing it buys at work: I notice drift before it becomes an incident, instead of after. A container that quietly picked up a privileged flag, a port that got published wider than intended, an unfamiliar MAC address on the network. These are exactly the kind of small, boring facts that are easy to miss and easy to detect deterministically.

It's not a real SOC. There's no 24/7 coverage, no incident response retainer, and the threat model is "don't get owned by something dumb," not "defend against a motivated attacker." But the muscle is the same one I use at work: write the check once, make it boring and deterministic, let a model help you read the output, and keep a record you can actually search six months later.

If you're already doing this professionally, the homelab version costs you an evening and pays you back the first time you catch something you would have otherwise missed entirely.

Stripe webhooks with NextJS

Adrien Fischer — Mon, 01 May 2023 07:09:49 +0000

Before we start

Stripe webhooks enable receiving notifications when an event occurs in your stripe account, such as payment or subscription creation, customer creation, among others.

Data received varies depending on the event: payment intent id, amount, currency, etc., for payment creation, for example.

This NextJS tutorial focuses on webhook management solely, not stripe integration for your application. Assuming that you have a stripe account and prior knowledge in payment intent or customer creation, we will cover setting up a webhook handler in NextJS.

Setup webhook in Stripe

Go to your stripe dashboard, then click on the "Developers" tab, then on "Webhooks".

Then click on "Add endpoint".

The url is the url of your NextJS application. For instance, if your application is deployed on Vercel, it will be something like https://your-app.vercel.app/api/webhooks.

Then, you need to choose the events you want to listen to. For instance, if you want to listen to the payment_intent.succeeded event, you need to select "Payment intent succeeded" in the "Event types" dropdown.

Then click on "Add endpoint".

Create a webhook handler

Lets jump right into the code. First, we need to create a handler that will be called when a webhook is received. We are going to create a file called webhooks.ts in the pages/api folder.

// pages/api/webhooks.ts
import { buffer } from 'micro';
import { NextApiRequest, NextApiResponse } from 'next';
import Stripe from 'stripe';

// This part is necessary so that NextJS doesn't parse the request body
// Otherwise it will manipulate it and stripe will reject it
export const config = {
  api: {
    bodyParser: false,
  },
};

// the handler
const handleWebhook = async (
  req: NextApiRequest, 
  res: NextApiResponse
  ) => {
  if (req.method === 'POST') {
    try {
      // get the stripe signature
      const sig = req.headers['stripe-signature'];
      const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
        apiVersion: '2022-11-15',
        typescript: true,
      });
      const buf = await buffer(req);
      const stripeEvent = stripe.webhooks.constructEvent(
        buf,
        sig!,
        process.env.STRIPE_ENDPOINT_SECRET!
      );
      // now you have access to the stripe event

      switch (stripeEvent.type) {
        // this is where we are going to add our logic 
        // depending on the event type
        case '':
          break;
        // ...
      }

      // just inform stripe that you received the event
      res.send({ status: 'success' });
      return;
    } catch (error: any) {
      // lets handle any errors coming from stripe
      console.log(error);
      res.status(500).json({ error: error.message });
      return;
    }
  }

  // if the request is not a POST request, we return a 404
  res.status(404).json({
    error: {
      code: 'not_found',
      message:
        "The requested endpoint was not found",
    },
  });
}

export default handleWebhook;

Event specific logic

Lets say you have a subscription for your software and you want to update your database with the subscription ID when the checkout session is completed. You can do something like this:

case 'checkout.session.completed':
  const session = stripeEvent.data.object as Stripe.Checkout.Session;

  const subscription = await stripe.subscriptions.retrieve(
    session.subscription as string
  );

  // update your database with the subscription id or status, ...

  break;

For the events list, you can refer to the stripe documentation.

Environment variables

As you can see, we will need 2 environment variables (locally in your .env.local file):

STRIPE_SECRET_KEY
STRIPE_ENDPOINT_SECRET

You can find them in your stripe dashboard, in the "Developers" tab, then "API keys".

Testing the webhook locally

Now that we have our webhook handler, we need to test it. The problem is that we can't test it locally because stripe needs to be able to send a request to our application. So we need to expose our local application to the internet.

The easiest way is to use stripe cli. You can download it here.

Then, you need to login to your stripe account:

stripe login

Then, you need to start listening to the events and forward the request to our local application.:

stripe listen --load-from-webhooks-api --forward-to localhost:3000

Now we can just use our app locally and debug the events based on our flow.

If you want to trigger a specific event, you can use the trigger command:

stripe trigger payment_intent.succeeded

Just as a general note, you should test in "test mode" first, then when you are ready, you can switch to "live mode".

NextJS api validators

Adrien Fischer — Mon, 17 Apr 2023 07:44:07 +0000

NextJS background

NextJS is a popular React framework for building server-rendered React applications. It provides a feature called "API Routes" that allows you to create serverless functions within your NextJS application to handle API requests.

API Routes in NextJS provide a convenient way to create server-side logic for handling HTTP requests, such as fetching data from a database, processing form submissions, or integrating with third-party APIs. These API Routes are automatically deployed as serverless functions and can be accessed via API endpoints.

To create an API Route in NextJS, you can create a file with the .js or .ts extension in the pages/api directory of your NextJS project. This file represents the API endpoint that you want to create. For example, you can create a file called myApi.ts in the pages/api directory to create an API endpoint with the URL path /api/myApi.

Inside the API Route file, you can define your server-side logic using JavaScript or TypeScript. You can use popular Node.js libraries for handling HTTP requests and responses, such as http, express, or axios. For example, you can define an API Route that handles a POST request and returns a JSON response like this:

// pages/api/myApi.ts

export default function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method === 'POST') {
    // Handle POST request logic here
    const { email, address } = req.body;
    // Process the data and send response
    res.status(200).json({ message: 'Data received', email, address });
  } else {
    res.status(400).json({ message: 'Invalid request method' });
  }
}

This is quite easy to setup and great to use.
Except when the application grows and you need to validate the data coming from the client.

For instance, if you want to have the same endpoint and handle the GET and the POST request, you can do something like this:

// pages/api/myApi.ts

export default function handler(req: NextApiRequest, res: NextApiResponse) {
    if (req.method === 'POST') {
        // your logic
        res.status(200).json({ message: 'Post method' });
    } else if (req.method === 'GET') {
        // your get logic
        res.status(200).json({ item: {name: 'my item', price: 0} });
    } else {
        res.status(400).json({ message: 'Invalid request method' });
    }
}

And if you need to validate the data coming from the client, you will need to add some logic to check if the data is valid or not.

That's when next-api-decorators comes in handy.

Main caveat: you handler needs to be a class rather than a function.

What you need to install

npm install next-api-decorators class-validator

So now, you can create a class that will handles our previous requests like so:

// pages/api/myApi.ts

class MyApiRouteHandler {
    @Post()
    @HttpCode(200) // will return a 200 if everything is ok
    createItem() {
        return { message: 'Post method' };
    }

    @Get()
    @HttpCode(200) // will return a 200 if everything is ok
    getItem() {
        return ({ item: {name: 'my item', price: 0} });
    }
}
export default createHandler(MyApiRouteHandler);

Way cleaner and easier to read.

Validation

Now lets add some validation to our request:

// pages/api/myApi.ts

export default class MyApiRouteHandler {
    @Post()
    @HttpCode(201) // will return a 201 if everything is ok
    createItem(
        @Body(ValidationPipe) body: ItemCreationDto,
        @Req() req: NextApiRequest,
        @Res() res: NextApiResponse
    ) {
        const { name, price } = body;
        return { message: 'Post method', name, price };
    }
}

We are using the ValidationPipe from class-validator to validate our request body.

class ItemCreationDto {
    @IsString()
    @IsNotEmpty()
    name: string;

    @IsNumber()
    @IsNotEmpty()
    price: number;
}

Now when you call your endpoint, you will get a 400 error if your body is not valid. So quite easy to use.
Now you can just insert your data in the database for instance without having to write extra code for validation.

Conclusion

In conclusion, NextJS API validator is a valuable tool for building secure and robust APIs in a TypeScript context. By leveraging its features for type checking, data validation, and sanitization, you can create APIs that are more resilient to common security risks, provide better error handling, and deliver a more reliable and secure user experience. Incorporating NextJS API validator in your NextJS TypeScript projects can greatly enhance the overall quality and security of your APIs.

Create a blog with Supabase and Next.js - part 5 - deployment

Adrien Fischer — Wed, 22 Mar 2023 14:36:52 +0000

Create a supabase account

Until now we've been using supabase locally with docker.
Lets create the necessary accounts so we can deploy our blog to the cloud.

Go to supabase and create an account, and then a project. We won't go into details about the project creation, you can find more information in the docs.

We have a couple of different ways of doing it, either by using the sql editor and copy pasting the migration file, or by using github actions.

If you created the database manually from the UI, you can just get the migration by running:
npx supabase db diff -f first-migration

Create a Github repository

Create a new repository or fork my repository if you haven't done everything on your side already.

Github actions

Lets go back to the database. What we want to do is deploy the database to supabase when we push to the main branch. We can do that by using github actions.

## .github/workflows/deploy-migrations.yml
name: Deploy Migrations to Supabase

## targets the main branch - when we push to main, the workflow will run
on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest

    env:
      SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
      SUPABASE_DB_PASSWORD: ${{ secrets.SUPABASE_DB_PASSWORD }}
      SUPABASE_PROJECT_ID: ${{ vars.SUPABASE_PROJECT_ID }}

    steps:
      - uses: actions/checkout@v3

      - uses: supabase/setup-cli@v1
        with:
          version: latest

      - run: |
          supabase link --project-ref $SUPABASE_PROJECT_ID
          supabase db push

We need to create a folder called .github/workflows and create a file called deploy-migrations.yml with the content above.

In github (Settings > Secrets and variables > Actions), we also need to create the following secrets:

SUPABASE_ACCESS_TOKEN
SUPABASE_DB_PASSWORD

And the following variable:

SUPABASE_PROJECT_ID

You can find the values in the supabase dashboard.

Deploying the blog

First we need to create a vercel account and link it to our github account. Once that's done, just create a new project.

Once again setup the supabase environment variables in the vercel dashboard. Those values are for Next.js this time.

And that's it, we're done. You can now go to your project and commit/push to the main branch to deploy the database and the blog.

Create a blog with Supabase and Next.js - part 4 - SSR

Adrien Fischer — Tue, 21 Mar 2023 07:56:06 +0000

If you want to jump straight to the source code, here's the link to the github repository.

One thing we haven't done yet is server side rendering. We are currently fetching the posts using the useEffect hook. This means that the posts won't be available until the component is mounted. We can do better by using the getStaticProps function from nextjs to fetch the posts on the server.

Lets use the /posts/[id] page to do just that.

export const getServerSideProps = async (ctx: GetServerSidePropsContext) => {
  const supabase = createServerSupabaseClient(ctx); // from '@supabase/auth-helpers-nextjs';
  const { data } = await supabase
    .from('posts')
    .select('*')
    .eq('id', ctx.params?.id)
    .single();

  if (!data) {
    // if the post doesn't exist, return 404
    return {
      notFound: true,
    };
  }

  // return the post a prop
  return {
    props: {
      post: data,
    },
  };
};

By using getServerSideProps, we can now fetch the post on the server and pass it to the component as a prop. Our PostPage component already have the post prop so we can just use it (see part 2).

Github actions: Deploy a Hugo website to a FTP server

Adrien Fischer — Mon, 20 Mar 2023 13:46:40 +0000

Introduction

Nowadays, it never has been easier to build and host a website for having any form of online presence. You don't even need a lot of web development knowledge. There are many tools and resources available that make the process easier than ever. One such tool is Hugo, a fast and flexible static site generator that allows users to create websites quickly and easily. In addition, deploying a Hugo site to a web server can be made even simpler through the use of Github Actions (assuming your code is hosted on github), a powerful automation tool that can be used to automatically deploy a website to a FTP server. In this article, we'll explore how to use Hugo to build a website and then deploy it to a FTP server using Github Actions, providing a step-by-step guide for those looking to get their website up and running quickly and efficiently.

Github actions

Github actions is a great tool to automate your workflow. It is free for repositories (with some limitations on private repositories) and you can use it to build, test and deploy your code.

Setting up the environment variables

You need to set up some environment variables in your repository. You can do this by going to Settings > Secrets & Variables > Actions in your Github repository (under Security).

You need to set up the following variables:

Creating the workflow

Now that we have the environment variables set up, we can create the workflow. You can create a file called main.yml in the .github/workflows folder in your repository.

The workflow consists of two jobs: "build" and "deploy". The "build" job builds the hugo site and the "deploy" job deploys the site to the FTP server.

name: 🚀 Deploy to prod

# Will trigger the workflow on each push to the main branch
on:
  push:
    branches:
      - main

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  # The first job will build the hugo site and upload the artifact
  build:
    name: 🔧 Build Hugo site
    runs-on: ubuntu-latest
    env:
      HUGO_VERSION: 0.111.2
    steps:
      - name: Install Hugo CLI
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
          && sudo dpkg -i ${{ runner.temp }}/hugo.deb

      - name: Install Dart Sass Embedded
        run: sudo snap install dart-sass-embedded

      - name: Checkout
        uses: actions/checkout@v3
        with:
          submodules: recursive
          fetch-depth: 0

      - name: Install Node.js dependencies
        run: '[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true'

      - name: Build with Hugo
        env:
          # For maximum backward compatibility with Hugo modules
          HUGO_ENVIRONMENT: production
          HUGO_ENV: production
        run: |
          hugo \
            --gc \
            --minify

      # We save the result as an artificat so we can use it in the next job
      - name: Upload artifact
        uses: actions/upload-artifact@v3
        with:
          name: release-artifact
          path: './public'

  # The second job will deploy the site to the FTP server using the artifact from the first job
  deploy:
    name: 🎉 Deploy
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      # Download the artifact we just created
      - name: Download artifact
        uses: actions/download-artifact@v3
        with:
          name: release-artifact
          path: './public' # This is the path where the artifact will be downloaded to

      - name: Deploy file
        uses: wlixcc/SFTP-Deploy-Action@v1.2.4
        with:
          server: ${{ vars.ftp_server }}
          username: ${{ vars.ftp_username }}
          ssh_private_key: ${{ secrets.ftp_password }}
          # or if you only use a password
          # sftp_only: true
          # password: ${{ secrets.ftp_password }}
          port: ${{ vars.ftp_port }}
          remote_path: '/var/www/app' # This will depend on your server
          local_path: './public/*' # This is the path where the artifact is located

Now you only need to commit and push your changes to the main branch and the workflow will be triggered.

Sources:

Other alternatives

You can deploy your hugo site to a lot of other services like Netlify, Vercel, Render, etc. You can find a list of all the services here.

Create a blog with Supabase and Next.js - part 3 - fetching data

Adrien Fischer — Mon, 20 Mar 2023 07:21:09 +0000

If you want to jump straight to the source code, here's the link to the github repository.

The `useSignIn` hook

We are going to create a hook to handle the signin process. We will use the useAuth hook from @supabase/auth-helpers-nextjs to handle the authentication. It returns an object with two methods: signInWithEmail and signOut.

import { useSupabaseClient } from '@supabase/auth-helpers-react';

const useSignIn = () => {
  const supabase = useSupabaseClient();

  const signInWithEmail = async (email: string) => {
    const { error } = await supabase.auth.signInWithOtp({
      email: email,
    });
    if (error) throw error;
  };

  const signOut = async () => {
    const { error } = await supabase.auth.signOut();
    if (error) throw error;
  };

  return { signInWithEmail, signOut };
};

export default useSignIn;

Here's a breakdown of the hook's functionality:

`signInWithEmail` method

The signInWithEmail method is an asynchronous function that takes an email address as an argument. It uses the Supabase client obtained from the useSupabaseClient hook to call the signInWithOtp method and attempt to sign the user in with a magic link.

The user will only need to check his/her email and click on the link to sign in.

`signOut` method

The signOut method is an asynchronous function that calls the signOut method of the Supabase client obtained from the useSupabaseClient hook to sign the user out of their account. If the sign-out attempt fails, the function throws the error.

The `usePosts` hook

import { useState } from 'react';
import { Database } from '@/types/database.types';
import { useSupabaseClient, useUser } from '@supabase/auth-helpers-react';
import { Post } from '@/types/Post';

const useGetPosts = () => {
  // Retrieve Supabase client and user from context
  const supabase = useSupabaseClient<Database>();
  const user = useUser();

  // Initialize posts state
  const [posts, setPosts] = useState<Post[]>([]);

  // Retrieve posts from the database
  const getPosts = async (limit?: number) => {
    const { data, error } = await supabase
      .from('posts')
      .select('*')
      .limit(limit || 50);
    if (error) throw error;
    setPosts(data || []);
  };

  // Create a new post in the database
  const createPost = async (title: string, body: string) => {
    if (!user) throw new Error('User not found');
    const { data, error } = await supabase
      .from('posts')
      .insert({
        title,
        body,
        author: user.id,
      })
      .select()
      .single();
    if (error) throw error;
    return data;
  };

  // Update an existing post in the database
  const updatePost = async (id: string, title: string, body: string) => {
    const { data, error } = await supabase
      .from('posts')
      .update({
        title,
        body,
      })
      .match({ id })
      .select()
      .single();
    if (error) throw error;
    return data;
  };

  return {
    getPosts,
    updatePost,
    createPost,
    posts,
  };
};

export default useGetPosts;

This custom hook provides functionality for retrieving and manipulating posts from a Supabase database.

Nothing too fancy about it, it's just a wrapper around the Supabase client. In terms of security, the RLS are already taking care of everything so we don't need to worry about that.

Lets integrate the hooks in the app

First lets do the signin page.

// --- src/components/SignupModal.tsx ---
const { signInWithEmail } = useSignIn();

const handleSubmit = async (evt: FormEvent<HTMLFormElement>) => {
  evt.preventDefault();
  try {
    await signInWithEmail(email);
  } catch (error: any) {
    console.log(error.message);
  }
};

Previously the posts array was just an empty array we were saving in the state. Now we are going to fetch the posts from the database. The useGetPosts hook provides a getPosts method that we can use to fetch the posts and a posts state that we can use to display the posts. So no changes to the UI.

// --- src/components/PostList
const { getPosts, posts } = useGetPosts();
useEffect(() => {
  getPosts();
}, []); // only on mount

Creating a post is pretty straightforward.

// --- src/pages/new.tsx ---
const router = useRouter();
const { createPost } = usePosts();

const handleSubmit = async (title: string, body: string) => {
  try {
    const { id } = await createPost(title, body);
    router.push(`/posts/${id}`);
  } catch (error: any) {
    console.log(error.message);
  }
};

We call the hook that will create a new post in the database and redirect the user to the newly created post if it succeeds.

And finally lets update the detail page the same way.

// --- src/pages/posts/[id].tsx ---
const router = useRouter();
const { updatePost } = usePosts();

const handleSubmit = async (title: string, body: string) => {
  try {
    await updatePost(post.id, title, body);
    router.reload();
  } catch (error: any) {
    console.log(error.message);
  }
};

The last step is to fetch the post and display them in the post page (/posts/[id]), based on the id in the url. To do that, we are going to do it differently and use the getServerSideProps function from Next.js.

Create a blog with Supabase and Next.js - part 2 - the UI

Adrien Fischer — Sun, 19 Mar 2023 07:15:31 +0000

If you want to jump straight to the source code, here's the link to the github repository.

The home page

Based on what we've done in the previous part, we are now going to create a component to display the posts called PostList.

// --- src/components/PostList.tsx ---
const PostList = () => {
  const [posts, setPosts] = useState<Post[]>([]);
  return (
    <Container>
      <Stack direction="horizontal" gap={3}>
        <h1>Latest posts</h1>
        <Link href={`/posts/new`} legacyBehavior>
          <Button>+ new post</Button>
        </Link>
      </Stack>
      <Row xs={1} md={2}>
        {posts.map((post) => (
          <Col key={post.id}>
            <PostCard post={post} />
          </Col>
        ))}
      </Row>
    </Container>
  );
};
export default PostList;

Nothing complicated, we just display the posts in a grid. We also have a button to create a new post.

Because we are using bootstrap, we need to use the legacyBehavior prop on the Link component to make it work. Now by default next/link creates a a tag with a href attribute. This is not compatible with bootstrap as bootstrap already creates a a tag with the Button component.

More info in the doc here.

Quick note about the types: we are using the Post type from the types/Post.ts file which uses the types from the database.
You can generate them by running: npm run dev:gen-types

Now we need a nav bar to display the login button and the title of the blog.

// --- src/components/Header.tsx ---
const Header = () => {
  const user = useUser(); // hook from '@supabase/auth-helpers-react';
  const [showModal, setShowModal] = useState(false);
  const handleLogout = () => {
    // logout logic will go here
  };
  return (
    <>
      <SignupModal show={showModal} handleClose={() => setShowModal(false)} />
      <Navbar bg="light">
        <Container>
          <Navbar.Brand href="#home">My Supabase blog</Navbar.Brand>
          <Navbar.Toggle />
          <Navbar.Collapse className="justify-content-end">
            {user ? (
              <Button variant="link" onClick={handleLogout}>
                Logout
              </Button>
            ) : (
              <Button onClick={() => setShowModal(true)}>Login</Button>
            )}
          </Navbar.Collapse>
        </Container>
      </Navbar>
    </>
  );
};
export default Header;

Those components will be used in the index.tsx file.

// --- src/pages/index.tsx ---
const Home = () => {
  return (
    <>
      {/* see previous step */}
      <main>
        <Header />
        <PostList />
      </main>
    </>
  );
};

The login modal 🔒

We are going to use the Modal component from bootstrap to display the login form so we don't need to create a separate page.

// --- src/components/SignupModal.tsx ---
const SignupModal = ({ show = false, handleClose }: Props) => {
  const [email, setEmail] = useState('');

  const handleSubmit = async (evt: FormEvent<HTMLFormElement>) => {
    evt.preventDefault();
    // login logic will go here
  };

  return (
    <Modal show={show} onHide={handleClose}>
      <Card body>
        <Form id="login" onSubmit={handleSubmit}>
          <Form.Group className="mb-3" controlId="formLoginEmail">
            <Form.Label>Email address</Form.Label>
            <Form.Control
              type="email"
              value={email}
              onChange={({ target }) => setEmail(target.value)}
            />
          </Form.Group>
          <Button type="submit" disabled={loading}>
            Login
          </Button>
        </Form>
      </Card>
    </Modal>
  );
};

export default SignupModal;

Post creation page

For this new page (/posts/new), we are going to keep the logic simple and in the page, the form will be a separated component called PostEditForm.

// --- src/pages/posts/new.tsx ---
const NewPostPage = () => {
  const handleSubmit = async (title: string, body: string) => {
    // create post logic will go here
  };

  return (
    <>
      <main>
        <Header />
        <Container>
          <Link href="/" legacyBehavior>
            <Button variant="link">{'<'}Back to all posts</Button>
          </Link>
          <h1>New Post</h1>
          <PostEditForm saveForm={handleSubmit} />
        </Container>
      </main>
    </>
  );
};

export default NewPostPage;

The PostEditForm component is pretty simple, it just displays a form with one input and a submit button.

// --- src/components/PostEditForm.tsx ---
const PostEditForm = ({ saveForm, post }: Props) => {
  const [title, setTitle] = useState('');
  const [body, setBody] = useState('');

  // if we are editing a post, we need to set the initial values on mount
  useEffect(() => {
    if (post) {
      setTitle(post.title);
      setBody(post.body);
    }
  }, [post]);

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    await saveForm(title, body);
  };

  return (
    <Form onSubmit={handleSubmit}>
      <Form.Group className="mb-3">
        <Form.Label>Title:</Form.Label>
        <Form.Control
          value={title}
          onChange={({ target }) => setTitle(target.value)}
        />
      </Form.Group>
      <Form.Group className="mb-3">
        <Form.Label>Content:</Form.Label>
        <Form.Control
          as="textarea"
          rows={3}
          value={body}
          onChange={({ target }) => setBody(target.value)}
        />
      </Form.Group>
      <Button type="submit">Save</Button>
    </Form>
  );
};

export default PostEditForm;

The post page and the edit page 📝

The post page will display the post and a button to edit it. The edit component will be the same as the new post component but with the initial values set.

// --- src/pages/posts/[id].tsx ---
const PostPage = ({ post }: Props) => {
  const [isEditing, setIsEditing] = useState(false);

  const handleSubmit = async (title: string, body: string) => {
    // update post logic will go here
  };

  return (
    <main>
      <Header />
      <Container>
        <Link href="/" legacyBehavior>
          <Button variant="link">{'<'}Back to all posts</Button>
        </Link>
        {isEditing ? (
          <PostEditForm post={post} saveForm={handleSubmit} />
        ) : (
          <>
            <h1>{post.title}</h1>
            <div>{post.body}</div>
            {user && user.id === post.author && (
              <Button onClick={() => setIsEditing(true)}>Edit post</Button>
            )}
          </>
        )}
      </Container>
    </main>
  );
};

The UI is now done, in the next part we will create the hooks to fetch the data from the database.

Create a blog with Supabase and Next.js

Adrien Fischer — Sat, 18 Mar 2023 11:35:41 +0000

If you want to jump straight to the source code, here's the link to the github repository.

Introduction

In this tutorial, we will build a simple blogging application using Next.js and Supabase. Next.js is a popular React framework for building server-side rendered and statically generated web applications, while Supabase is an open source Firebase alternative that provides a PostgreSQL database and authentication APIs out of the box. By combining these technologies, we can easily create a performant and scalable blogging platform.

Throughout this tutorial, we will cover the following topics:

Setting up a Next.js project and integrating Supabase for authentication.
Creating a PostgreSQL database schema for our blog application using Supabase.
Implementing server-side rendering and client-side routing with Next.js.
Building a user interface for creating, editing, and deleting blog posts using React components.
Deploying our application to the cloud using Vercel.

By the end of this tutorial, you will have a fully functional blog application that can be customized and expanded to suit your needs. So let's get started!

Setup our project

Create a new project with next.js and typescript:

npx create-next-app@latest --typescript

Install supabase and bootstrap:

npm install supabase --save-dev
npm install @supabase/supabase-js
npm install @supabase/auth-helpers-nextjs @supabase/auth-helpers-react
npm install react-bootstrap bootstrap

Now we can initialize supabase:

npx supabase init

Which will create the supabase folder with the config, and finally, start all the services:

npx supabase start

Now for the Next.js part, we need to create a .env.local file in the project root and add the following environment variables (see the screenshot below for the values):

NEXT_PUBLIC_SUPABASE_URL=<your-supabase-api-url>
NEXT_PUBLIC_SUPABASE_KEY=<your-supabase-api-key>

Lets start the dev server:

npm run dev

We are good to go!

The database

We only need a posts table with the following columns:

create table "public"."posts" (
  "id" uuid not null,
  "title" text not null,
  "body" text not null,
  "created_at" timestamp with time zone default now(),
  "author" uuid not null
);

CREATE UNIQUE INDEX posts_pkey ON public.posts USING btree (id);

alter table "public"."posts" add constraint "posts_pkey" PRIMARY KEY using index "posts_pkey";
alter table "public"."posts" add constraint "posts_author_fkey" FOREIGN KEY (author) REFERENCES auth.users(id) not valid;
alter table "public"."posts" validate constraint "posts_author_fkey";

You can either create the table manually, or use the supabase dashboard.

Quick note on the author column: we are using directly the uuid from the auth.users table.
Usually as a good practice I would create a profiles table with the id as the primary key and additionnal infos (like the name, the avatar, etc...).
But for this tutorial I will keep it simple.

Lets turn on RLS (Row Level Security) for the posts table, and authorise everyone to read the table, any logged in user to create posts, and finally only the owner can update:

alter table "public"."posts" enable row level security;

create policy "everyone can see posts"
on "public"."posts"
as permissive
for select
to public
using (true);

create policy "only logged in users can create posts"
on "public"."posts"
as permissive
for insert
to authenticated
with check (true);

create policy "only the user can edit"
on "public"."posts"
as permissive
for update
to public
using ((auth.uid() = author))
with check ((auth.uid() = author));

You can see (and actually create/edit) those policies in the supabase dashboard:

Note: no delete for now - so I've kept it out of the policies - but it would be the same, only owners can delete.

NextJs setup

Lets get rid of the default page in the pages folder and replace the index.tsx with the following:

import Head from 'next/head';
const Home = () => {
  return (
    <>
      <Head>
        <title>Posts list</title>
        <meta name="description" content="Blog made with NextJs and Supabase" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main>{/* Our components will go here */}</main>
    </>
  );
};
export default Home;

As a reminder, the pages folder is a special directory in a Next.js project that contains the pages of your application. When you create a new file in this folder, Next.js automatically generates a route for it based on the file name. For example, the index.js in the pages folder, it will be mapped to the root URL of your application.

For our application, we will have the following pages:

/: the home page, which will list all the posts
/posts/[id]: the post detail page
/posts/new: the new post page

In terms of structure, our src folder will look like the following:

So to recap, we will have:

components: our React components
hooks: our custom hooks for getting/setting data from supabase
pages: our Next.js pages
styles: for some custom styling
types: for our database types

Everything is now ready, lets jump on the UI!

DEV Community: Adrien Fischer

From Prompts to Pipelines: How I Use Agentic Coding as an Engineering Workflow

What makes this interesting to me

What the repository actually provides

How the pipeline is driven

How I set it up

What it looks like on a small task

Why the staged flow matters

When I reach for it

Where this can break down

The main lesson

Designing Single-Purpose Agents Instead of One Big Automation Script

The three conventions that make this work

Why decompose instead of consolidate

The boring plumbing is the point

My homelab stack in 2026: what runs, why, and how it all connects

The foundation

Traefik

Tailscale

CoreDNS

Dev & CI/CD: the pipeline

Gitea

Woodpecker CI

Local Docker registry

WUD - What's Up Docker

Local AI: Ollama + OpenWebUI

Search: SearXNG

Documents: Paperless-NGX + Paperless-AI

Password management: Vaultwarden

Monitoring & management

Prometheus

Portainer

Homer

Communication & file sharing

Ntfy

Pairdrop

Home automation: Home Assistant

What's next

Running a Personal SOC: Bringing Production Security Practices Home

Two layers, not one

Where the LLM fits - and where it doesn't

The part that's just operational discipline

What it actually buys me

Stripe webhooks with NextJS

Before we start

Setup webhook in Stripe

Create a webhook handler

Event specific logic

Environment variables

Testing the webhook locally

NextJS api validators

NextJS background

What you need to install

Validation

Conclusion

Create a blog with Supabase and Next.js - part 5 - deployment

Create a supabase account

Create a Github repository

Github actions

Deploying the blog

Create a blog with Supabase and Next.js - part 4 - SSR

Github actions: Deploy a Hugo website to a FTP server

Introduction

Github actions

Setting up the environment variables

Creating the workflow

Other alternatives

Create a blog with Supabase and Next.js - part 3 - fetching data

The useSignIn hook

signInWithEmail method

signOut method

The usePosts hook

Lets integrate the hooks in the app

Create a blog with Supabase and Next.js - part 2 - the UI

The home page

The login modal 🔒

Post creation page

The post page and the edit page 📝

Create a blog with Supabase and Next.js

Introduction

The `useSignIn` hook

`signInWithEmail` method

`signOut` method

The `usePosts` hook