DEV Community: p0wikkk

I was managing servers before I could legally sign a contract

p0wikkk — Sun, 26 Jul 2026 11:50:21 +0000

I got into Minecraft server administration at 12 - before I'd written a line of code, just clicking around config files and copying commands from forum posts, trying to figure out why my plugins kept conflicting with each other at 11pm on a school night. That's actually what pulled me into programming: I started at 13 with HTML, CSS, and JS, mostly so I could stop guessing and actually understand what I was editing.

A few years later, around 16, I picked up Lua and started running a FiveM server - right around when the whole FiveM roleplay scene was blowing up (this was the NoPixel-era boom, if that means anything to you). I ended up being decent at it - good enough that I was one of the more sought-after Lua/FiveM developers on the Polish scene at the time, picking up work for other servers on top of running my own. Different game, same underlying job: SSH into a box, fight with configs, figure out why the server crashed the moment more than a handful of people tried to join.

Nobody sat me down and explained SSH, cron jobs, or why my server kept crashing under load. I learned it the way most of us actually learn things - by breaking something at 1am and googling the error message until it made sense.

The part nobody tells you about running a server as a kid

Running a Minecraft or FiveM server isn't really about the game. It's server administration with extra steps. You're dealing with:

SSH into a box you're renting with money you definitely should've spent on something else
Config files that silently break everything if you get one line wrong
Backups you don't think about until the day you desperately need one
Plugin/resource conflicts that make no sense until you realize two mods are fighting over the same event hook
Actual human beings (your players) who notice immediately when the server goes down, and who are not shy about telling you in chat

I didn't have a mentor for any of this. I had a terminal, a PuTTY window, and a community of people online sharing scraps of documentation. It was frustrating in a way that, looking back, was probably the best possible education I could've gotten. When something breaks and there's no support ticket to open, you learn to actually read logs instead of skimming them.

Cybersecurity, and why I started caring about "who has access to what"

A few years later, in my late teens, I got into cybersecurity on the side. That's when the server admin instincts I'd built running game servers turned into something more deliberate - thinking about attack surface, who has SSH access to what, why a "temporary" open port from six months ago is still open. Running a public game server as a minor is, unintentionally, a decent crash course in "someone is always trying to get in."

Somewhere in there I also ran a couple of small local businesses - car detailing, paving stone and facade cleaning. Different world entirely, but the same underlying lesson kept showing up: infrastructure you don't understand or don't control will eventually cost you, whether that's a rented pressure washer or a rented VPS.

Why this ended up shaping PtyXL

I didn't set out to build an SSH client because of some grand plan. It came from a much more annoying, specific irritation: modern terminal clients increasingly want to sync your host list, your keys metadata, sometimes your session data, to their cloud. Convenient, until their service has a bad day and you can't get into your own box - the same box you've been SSH-ing into since you were twelve, just with better hardware now.

PtyXL is local-first on purpose. Keys and configs stay on your machine, full stop. If I've learned anything from a decade of managing servers I probably had no business managing at the time, it's that the tool should never be the thing standing between you and your own infrastructure.

If you also cut your teeth running some janky self-hosted server as a teenager - Minecraft, FiveM, or something else entirely - I'd genuinely like to hear how you got into it. That path seems to produce a specific kind of stubborn, hands-on engineer, and I'm curious how common it actually is.

Why I stopped trusting cloud-synced SSH clients (and built my own)

p0wikkk — Wed, 22 Jul 2026 23:01:35 +0000

I've been building an SSH/SFTP client that doesn't phone home - here's PtyXL

For the last while I've been heads-down on a side project that turned into something I actually use every day now.

Why I started this

I got tired of the "modern" SSH clients that quietly sync your host list, keys metadata, and sometimes session logs to a cloud backend. Convenient, sure, until their auth service has a bad day and you can't get into your own servers. I wanted something where my config lives in a file on my disk, my keys never leave my machine, and the whole thing works fully offline - coffee shop wifi, flaky VPN, doesn't matter.

So I built it. Rust + Tauri + React under the hood, so it's a real native app, not an Electron wrapper pretending to be one.

What it actually does
SSH, SFTP, and serial in one client, dual-panel SFTP if you're moving files around a lot
Session recording and snapshots, useful when you need to hand off or debug something later
An assistant that helps with connection management and config - but it runs against local state, not a hosted API. No shipping your infra topology to someone else's inference endpoint just to get autocomplete.
Recently shipped a "Provision Builder" - lets you wire up server configs and pipelines by connecting logic tiles instead of writing raw shell scripts by hand. Still early, but it's already saved me from a few dumb copy-paste mistakes.

Where it's at right now

It's genuinely early - I'm a solo dev on this, still shaping a lot of the roadmap based on whoever's willing to poke at it and tell me what's broken or missing. Free tier covers unlimited sessions, there's a Pro tier for people who want the heavier features, and I just put together a small program offering free Team access to early-stage startups (mostly because I remember what it's like trying to justify tool spend before you have revenue).

What I'd actually love from this post

Not really looking for a pat on the back - I'd rather hear what's annoying about it. If you manage servers regularly and try it out, tell me what's missing, what's confusing, what you'd rip out entirely. That feedback is worth more to me right now than downloads.

Happy to answer anything about the Rust/Tauri side too, or why I made specific tradeoffs around the local-first approach- ask away in the comments.

Also - if a few of you want to actually try it out properly, drop a comment and I'll hook you up with a free Pro plan. Would rather have a handful of people using it seriously than a pile of installs that go nowhere.

Are we losing control? Why I'm shifting to a "local-first" philosophy for my dev tools.

p0wikkk — Sun, 19 Jul 2026 00:28:06 +0000

Hey everyone,

Lately, I’ve been thinking a lot about the tools we use every day. We’ve all gotten used to "cloud-everything" - SaaS dashboards, web-based editors, and tools that require an active internet connection just to perform basic tasks.

But recently, I started asking myself: does my terminal really need to be in the cloud? Should my infrastructure management tool rely on a third-party server to function?

I’ve been moving toward a local-first approach for my development environment. For me, it’s not just about speed (though the performance boost is massive), but about:

Ownership: If the server goes down, my workflow shouldn't stop.

Privacy: My configurations and credentials stay on my machine, not on someone else's server.

Reliability: I want my tools to work just as well in a coffee shop with spotty Wi-Fi as they do in the office.

I’m curious - do you prioritize local-first capabilities when choosing your dev tools? Do you find yourself actively avoiding SaaS-only solutions in favor of native, self-hosted, or local-first alternatives? Or do you think the convenience of the cloud outweighs these concerns?

Let’s discuss. What’s your take on the current state of developer tooling?