DEV Community: Roger Castro

I Thought Portfolios Weren't for People Like Me. So I Built a Wiki Instead.

Roger Castro — Wed, 06 May 2026 19:17:48 +0000

For a long time I operated under a quiet assumption: portfolios are for developers. They're for people who build things — apps, tools, open source projects. People who have something to show.

I'm in IT support. I fix things. I troubleshoot. I answer tickets. What was I going to put on a portfolio page — a screenshot of a closed ticket?

So when I started wanting a way to document and showcase my work, I didn't build a portfolio. I built a wiki.

Why I Started Documenting

My homelab had been growing for a while. pfSense for routing, Pi-hole for DNS, a dedicated Docker host, a storage server, Tailscale for remote access. It was becoming real infrastructure — and real infrastructure has a way of becoming mysterious over time.

I'd seen it professionally at Datto too, just from a different angle. In technical support, documentation wasn't about managing someone else's environment — it was about continuity. When a partner called in on an ongoing ticket, good notes meant you knew exactly what had been tried, where things stood, and what to do next. When you hit a wall diagnosing something, you could search past tickets and find a case where someone else had solved the same thing. Documentation wasn't optional — it was the difference between resolving a ticket efficiently and spinning your wheels every time someone called in.

I didn't want that to happen to my own network. So I set up BookStack — a self-hosted, open source wiki — in a Docker container and started writing things down.

The first entries were practical. How the network is laid out. What IP addresses belong to what. How services are connected. The kind of information that feels obvious when you set something up and completely vanishes six months later when something breaks at 11pm and you're staring at a config file wondering what past-you was thinking.

It Grew Into Something More

What started as homelab documentation didn't stay there.

BookStack's structure — shelves containing books, books containing chapters, chapters containing pages — made it easy to expand into other areas. I added a Recipes shelf for cooking. A Subway Knowledge Base shelf for the SOPs and scripts I was writing at work, partly for reference and partly so I had a record of the processes I'd built or improved.

That work shelf in particular felt significant. I was documenting the Autopilot reimaging workflow I'd fixed, the processes I'd written up, the tools I'd built. I was building a record of my own professional contributions — not because anyone asked me to, but because I wanted it to exist.

I also started an Apollo Archives shelf — a growing reference library for certifications and courses I'm working toward, collected and organized for when I'm ready to dig in.

At some point I realized what I was actually doing. I was building a portfolio. I just hadn't called it that.

The Assumption I Had Wrong

Here's what I'd gotten wrong about portfolios: I thought they were about showing off projects. Things you built from scratch. Code you wrote. Apps you deployed.

But a portfolio is really just evidence of how you think and what you've done. It doesn't have to be a GitHub repo. It can be documentation. It can be a write-up of a problem you solved. It can be a structured record of the processes you've improved and the things you've learned.

IT support people build things all the time. We build processes. We build runbooks. We build muscle memory for diagnosing problems that would take other people hours. We just rarely write it down in a way that's visible to anyone else.

The wiki forced me to write it down.

What's in There Now

The nora.local Homelab shelf documents everything about my home network — infrastructure overview, network and DNS configuration, services and containers, backup and recovery procedures, a running change log, and a troubleshooting section for issues I've worked through.

Every Docker container gets a page. Every significant config change gets a change log entry. If I make a decision — why I chose Unbound over a forwarding resolver, why I run ZFS on both servers, why I set up WeTTY instead of direct SSH — I write down the reasoning, not just the steps.

That last part matters more than I expected. Steps tell you what was done. Reasoning tells you why, and why is what you actually need when something breaks or you're deciding whether to change it.

The Unexpected Side Effect

When I eventually decided to build an actual portfolio site — after realizing that yes, IT support people can have portfolios, and yes, I had more to show than I thought — the wiki had already done most of the work.

The project descriptions, the process write-ups, the technical details I needed to articulate my experience clearly — it was all there. Years of documenting my own work, organized and searchable, in my own words.

I didn't have to reconstruct what I'd done. I'd been writing it down the whole time.

If You're in IT and You're Not Documenting

Start.

You don't need BookStack specifically. A Notion workspace, a simple GitHub repo with markdown files, even a folder of well-named text documents — the tool matters less than the habit.

Document what you build. Document what you fix. Document the decisions you make and why you made them. Write it for future-you who will absolutely forget, and write it like someone else might need to understand it someday.

Because they might. And that someone might be a hiring manager.

Are you in IT support and wondering whether a portfolio is even worth building? I'd love to hear where you're at in the comments — this is a conversation I think our corner of the industry needs to have more.

How I Finally Got Remote Access to My Homelab (And the Workaround That Made It Actually Work)

Roger Castro — Wed, 06 May 2026 18:41:04 +0000

For a long time, my homelab had a dirty secret: I couldn't access it remotely.

Well, that's not entirely true. I used to have a solution — Google Remote Desktop into my main PC, then SSH from there into my servers using XShell. It worked, but it was clunky, dependent on my desktop being on and reachable, and felt like the wrong answer. When I eventually rebuilt my PC, I never bothered to set it up again.

So for a while, if I wasn't home, I wasn't in my homelab. For a network I'd put real effort into building — pfSense firewall, Pi-hole, Unbound, a dedicated Docker host, a storage server — that felt like a gap worth closing.

The solution turned out to be Tailscale. Getting it fully working took a detour I didn't expect.

Why Tailscale

I'd heard about Tailscale for a while before actually setting it up. The pitch is simple: install it on your devices, and they form a secure mesh VPN — no port forwarding, no dynamic DNS headaches, no managing certificates. Each device gets a stable Tailscale IP that works anywhere.

What sold me was installing it on my pfSense router (fireclaw in my homelab, following a Horizon Zero Dawn naming convention I use throughout). Installing Tailscale at the router level means every device on my local network is reachable through Tailscale — not just the ones with the client installed. One install, whole network covered.

After setting it up, I could reach my services from my phone or laptop from anywhere. Portainer, Uptime Kuma, Nginx Proxy Manager, BookStack — all accessible as if I was sitting at home. For a homelab that had been effectively offline to me whenever I left the house, this was a big deal.

The SSH Problem

With Tailscale on pfSense working well for web-based services, the next thing I wanted was SSH access to my servers — specifically minerva (Docker host) and zero-dawn (storage server).

This is where things got interesting.

When I tried to SSH directly into minerva from my laptop (hephaestus) over Tailscale, it would time out. Connection refused. Couldn't be reached. This was confusing — Tailscale was working fine for everything else, both hephaestus and fireclaw had Tailscale installed and connected, so why couldn't I reach minerva?

The suspected culprit: a routing loop. Traffic from hephaestus was hitting Tailscale, routing through fireclaw, and somewhere in the handoff between Tailscale and the local network it was getting lost — likely looping back into pfSense without finding its way to minerva. Firewall rules and routing tables on pfSense can get opinionated about traffic that arrives and leaves on the same interface.

The obvious fix was to install Tailscale directly on minerva, giving it its own Tailscale IP that hephaestus could reach directly without routing through pfSense at all. I tried it. SSH worked.

But something else broke.

One Fix, One New Problem

Installing Tailscale directly on minerva interfered with how its Docker containers were being reached. The details got murky fast — container networking, Tailscale's network interface, and pfSense all have opinions about routing, and they weren't agreeing. Services that had been working fine were suddenly unreachable.

At this point I had two options: dig into the networking conflict and try to resolve it, or find a different path to SSH that didn't require touching minerva's network config.

I chose the workaround.

WeTTY: Browser-Based SSH in a Docker Container

The insight was simple: I could already reach Docker containers on minerva through Tailscale without any issues. What if one of those containers was the SSH client?

WeTTY (Web TTY) is a Docker container that runs a terminal emulator in the browser. You access it over HTTP/HTTPS, and from inside it you can SSH into other machines on the same network. Since WeTTY and minerva are on the same local network, an SSH connection from WeTTY to minerva is just local traffic — no Tailscale routing involved, no pfSense interference.

The flow became:

Connect to Tailscale on hephaestus (or just have it running in the background)
Open a browser, navigate to the WeTTY container via its Tailscale-accessible address
SSH into minerva from WeTTY

It's one extra hop, but it's invisible in practice. From my laptop, opening a browser and navigating to WeTTY feels no different than opening a terminal — and I get a full SSH session into minerva from anywhere in the world.

What the Setup Looks Like Now

Tailscale on fireclaw (pfSense) — whole network reachable remotely
WeTTY in Docker on minerva — browser-based SSH terminal, accessible via Tailscale
Tailscale on hephaestus — laptop connects to the mesh from anywhere

From my phone I can check Uptime Kuma, manage containers in Portainer, and browse my BookStack wiki. From my laptop I can do all of that plus SSH into minerva via WeTTY for anything that needs a terminal.

It's not a perfect architecture. Ideally I'd resolve the routing conflict properly and SSH directly into minerva. But it works reliably, it's low maintenance, and it solved the actual problem: I can now manage my homelab from anywhere without being tethered to my desk at home.

The Takeaway

Sometimes the clean solution creates new problems, and the workaround is the right answer — at least for now. Homelab work is iterative. The goal isn't a perfect network on paper, it's a network that actually does what you need it to do.

Tailscale made remote access trivially easy. WeTTY filled the one gap Tailscale's pfSense integration left open. Together they gave me something I should have had a long time ago.

Running a similar setup or hit the same pfSense routing issue? I'd love to hear how you solved it in the comments.

We Were Reimaging Laptops the Hard Way for 3 Years. I Fixed It in an Afternoon.

Roger Castro — Wed, 06 May 2026 18:11:32 +0000

When I joined the IT team at a corporate headquarters, one of my first tasks was learning the reimaging process. We had a long counter lined with 12 to 18 laptops at a time, and the process went something like this:

Go to Intune, delete the device record, enrollment record, and Azure AD record
Walk to the laptop, boot from a Windows 11 USB installer, perform a clean install
Wait. Perform all Windows Updates — drivers too — while the device is unmanaged
Walk back to the laptop, run a PowerShell script to capture the hardware hash, which exports to a CSV on a USB drive
Walk back to your desk, manually upload the CSV to Intune to recreate the enrollment record
Walk back to the laptop, initiate Autopilot pre-provisioning
Wait for provisioning to complete
Reseal the laptop, put it on the shelf

Start to finish: roughly 6 hours per batch, assuming no hiccups. And there were always hiccups.

Something Felt Off

A few things didn't sit right with me from the start.

Why were we deleting the device record and starting completely from scratch? Why were we installing an old version of Windows 11 from a USB, only to spend hours downloading updates to get it current again? Why were we making three or four trips back and forth between the desk and the counter for every single batch?

And most importantly — Windows has built-in features specifically designed for this use case. Autopilot Reset and Fresh Start exist precisely so you don't have to blow everything away and start over. Why weren't we using them?

So I asked.

The answer I got from the engineers: "Because it doesn't work."

Okay. When was the last time you tried?

"About three years ago. Now we just do it manually."

I Just... Tried It

No lengthy investigation. No ticket. I grabbed a test device, initiated an Autopilot Reset, and waited.

It worked.

Autopilot Reset wiped the device, preserved the Windows version and existing updates, kept the Intune enrollment record intact, and left the laptop clean and ready for the next user — all without touching Intune, uploading a CSV, or reinstalling Windows from scratch.

Then I tried Fresh Start as well, for cases where a deeper clean was warranted. That worked too.

The reason the engineers had written it off three years ago? Likely a policy misconfiguration or a known Autopilot bug from that era that had long since been resolved. Nobody had ever gone back to verify. The broken process had just become the process.

The New Workflow

We settled on Autopilot Reset as the standard for reimaging, with Fresh Start available as a fallback for more stubborn devices.

The new process:

Initiate Autopilot Reset on the device
Wait for the wipe and reset to complete
Pre-provision via Autopilot
Reseal and shelf

That's it.

Because the device was already enrolled in Intune and already up to date before the reset, we skipped the USB install, skipped the hours of Windows Updates, skipped the hash capture and CSV upload, and eliminated most of the back-and-forth.

6 hours down to 2. For a batch of 12 to 18 laptops, that's a significant chunk of time back in everyone's day.

Writing It Up

After validating the new workflow, I wrote it up as a formal KB article and worked with the team to train other staff on the updated process. Autopilot Reset became the new SOP for device reimaging across the organization.

The Lesson

This wasn't a complex fix. It didn't require deep technical knowledge or a clever workaround. It just required someone to ask why — and then actually try the thing that everyone had assumed was broken.

Assumptions have an expiration date. Autopilot and Intune have both changed significantly over the past three years. Something that was broken or unreliable in 2021 might work perfectly fine today.

If your team has a process that exists because "we tried the right way once and it didn't work" — it might be worth trying again.

Have you inherited a broken process that turned out to have a simple fix? I'd love to hear about it in the comments.