DEV Community: ByteStrix

I got tired of SSHing into 10 VMs a day, so I built a live map of my whole infrastructure

ByteStrix — Thu, 13 Aug 2026 20:12:44 +0000

Every day at work looked the same. Something breaks, or I need to push a new image, and I'm SSHing into three different VMs, running docker ps on one, kubectl get pods on another, piecing together in my head what's actually connected to what. The official Kubernetes dashboard never stuck for me either, and I never bothered installing Lens everywhere I needed it.

At some point I just wanted one thing: open a browser tab and see everything. Not a list. An actual map, where I can see a VM, the containers on it, a Kubernetes namespace next to it, and how they talk to each other.

So I built it. It's called InfraCanvas, and I want to show the two ways you can connect something to it, because I think the "how easy is this actually" question matters more than any feature list.

Way 1: you already have a kubeconfig? You're done.

If kubectl get pods works for you right now, InfraCanvas works for you right now. No agent, nothing installed on your cluster, nothing to configure. Open the dashboard, click "Add cluster," drop your kubeconfig file in, pick a context if it has more than one. That's it — within a few seconds your nodes, namespaces, deployments, pods and services show up on the canvas, color coded by health. It just talks to your cluster's API server the same way kubectl does. The kubeconfig gets encrypted before it's stored, never logged anywhere.

One honest caveat, because I'd rather tell you now than have you hit it yourself: if your kubeconfig came from aws eks update-kubeconfig or gcloud container clusters get-credentials, it authenticates through a CLI plugin, and that can't run from a backend that isn't your own machine. Self-hosting InfraCanvas on your own box? Not an issue, the plugin runs right there. Using the hosted version? There's a small relay pod you deploy instead, one kubectl apply, connects outbound from inside your cluster. The UI tells you upfront which kubeconfigs need this instead of just failing silently on you.

Way 2: plain VMs, one command. Not everything is Kubernetes — a lot of real infrastructure is a VM running Docker, or systemd services, or a Node process someone started with PM2 in 2022 and never touched again. One install command from the dashboard, a small Go binary as a systemd service, streams everything up over a single outbound WebSocket. No inbound ports.

What you get once it's connected: a real terminal into a pod or host, live logs, restart a container or service, scale a deployment, edit a manifest and apply it, all without leaving the browser. None of this is groundbreaking alone — what I haven't found anywhere else is all of it on one map instead of scattered across a terminal, a cloud console, and a dashboard that only understands one of the two.

It's open source (AGPL) — code's on GitHub: https://github.com/bytestrix/InfraCanvas. Hosted version if you'd rather not run anything: https://infracanvas.app

I'm still early, small project, built mostly solo — if you try it and something's rough, I'd genuinely like to hear about it.

I Got Tired of SSH-ing Into Servers Just to Restart a Container, So I Built a Visual Control Plane

ByteStrix — Tue, 07 Jul 2026 06:37:08 +0000

If you've worked with Docker or Kubernetes for any amount of time, you've probably done something like this:

SSH into a server
Check running containers
Copy a container ID
Restart a service
View logs
Repeat on another server

It works.

But after doing it hundreds of times, I started wondering:

Why am I still managing infrastructure almost entirely through the terminal for common day-to-day operations?

Don't get me wrong—I love the CLI. It's incredibly powerful.

The problem is that many operational tasks don't necessarily need to be command-line driven.

The Pain

Imagine managing multiple environments.

Production.

Staging.

Development.

Different Docker hosts.

Several Kubernetes clusters.

Every time something needs attention, you're switching terminals, remembering commands, checking contexts, and hoping you're operating on the right environment.

Even experienced engineers occasionally run:

kubectl config current-context

...just to make sure they're not about to restart production.

What I Wanted

I wanted a single place where I could:

Visualize my infrastructure
Connect Docker hosts and Kubernetes clusters
Inspect workloads
Restart services
Scale deployments
View logs
Execute common operations

...without replacing the CLI.

Instead, I wanted something that complements it.

Building InfraCanvas

That's why I built InfraCanvas.

The idea is simple:

Your infrastructure becomes visual.

Instead of remembering where everything lives, you can actually see it.

Servers, clusters, namespaces, pods, containers—they're all represented visually while still exposing the power you'd expect from native Docker and Kubernetes operations.

Rather than jumping between multiple terminals and dashboards, everything is accessible from one interface.

Things I'm Focusing On

Current areas I'm working on include:

Docker host management
Kubernetes cluster management
Interactive infrastructure visualization
Container logs
Restart/start/stop operations
Scaling workloads
Secure remote connections
RBAC support
AI-assisted operations (still evolving)

The goal isn't to hide complexity.

It's to reduce unnecessary friction.

Lessons Learned

Building infrastructure software is very different from building a CRUD application.

You quickly run into challenges like:

Authentication
Secure remote execution
Cluster permissions
Different Kubernetes versions
Docker API quirks
Performance with large environments
Real-time updates

Every feature teaches something new.

I'd Love Feedback

I'm still actively building InfraCanvas, and I'd genuinely appreciate feedback from people who manage containers or Kubernetes in production.

Some questions I'm especially interested in:

What repetitive infrastructure task annoys you the most?
Which operation do you wish required fewer commands?
Would a visual control plane make your workflow better—or would you stick to the CLI?

I'm trying to build something that helps engineers rather than replacing the tools they already love.

I'd love to hear your thoughts.

What's your setup for managing more than 5 servers?

ByteStrix — Fri, 03 Jul 2026 05:50:47 +0000

Once I got past a couple of machines, SSH-ing into each to run
docker/kubectl/systemctl stopped scaling. Curious how others handle
it, one tool, a stitched-together stack, or just tmux and grit?
Where does your approach start to hurt?

I built a live map of my servers so I'd stop SSHing into 5 boxes to debug one thing

ByteStrix — Tue, 30 Jun 2026 11:09:41 +0000

I kept SSHing into servers and running the same commands just to see what was running:

kubectl get pods
docker ps
systemctl status
top

Different tools, different boxes, no single picture. So I built InfraCanvas.

You install one agent on a Linux server. It draws everything — Kubernetes, Docker, systemd, processes — as one live map. Color-coded by health, updates in real time.

Click anything to see its details. And you can act right there: restart, scale, rollback, open a terminal, tail logs. No SSH.

A few things I cared about building it:

Agent is outbound-only — no ports to open, no firewall changes.
Secrets stay home — secret env vars get redacted before they leave your server.
Runs as your user, not root.

Try it (read-only demo, no signup): https://demo.infracanvas.app
Free tier on your own box: https://cloud.infracanvas.app

I'm a solo dev. Honest question: does seeing infra as a map actually help, or is kubectl muscle memory good enough? Tell me where it breaks.