Titus Muli

Spent weeks building an agent harness that could actually be trusted near prod. Today it listed services, found the right managed database, requested approval with a risk rating and expiry, attached postgres to my apis container, and injected the env vars then asked before redeploying. Worth every late night.

Built Domain specific harness, Alie,then handed it a container problem to see what happened. It looked at the infrastructure, followed the evidence, and helped me diagnose the issue. Somewhere, a chatbot is still confidently blaming the Dockerfile.

I think private cloud is the future of self-hosting. As the AI boom keeps pushing compute demand and infrastructure costs higher, owning and operating your own compute starts to make more sense.

beaver deploy That's it From the folder on my laptop → built → deployed → running on my own infrastructure. I keep looking for more steps to add to the demo but that would defeat the purpose 😂 Self-hosting with fewer rituals.

Just made container management in @vectorihub using beaver easy as git push You can now beaver containers → list your containers beaver container <name> redeploy → redeploy beaver container <name> rollback → restore the previous healthy deployment No SSH, no manually hunting for the last working image. Rollback was one of those things I really wanted Beaver to make boring.

Just shipped beaver deploy No dashboard. No clicking around. You’re already in your terminal, so now you can just run beaver deploy and ship your app to your own VPS. Still SSH-free under the hood, the CLI talks to the Beaver agent already running on your machine. Your infrastructure. One command. App live

I’m now using Edge on @vectorihub blog itself. The site in this screenshot is still deployed where I want it Beaver Edge simply sits in front of it. That’s the idea. You don’t have to migrate your app to vectorihub to use Beaver Edge. Keep deploying on: • Vercel • your VPS • AWS • DigitalOcean • wherever your app already lives Then connect your domain to Beaver Edge and get the traffic, security, request visibility, firewall, and edge tooling around it. I’m dogfooding it on my own infrastructure every day and fixing the problems I find. If you already have an app deployed somewhere, I’d love for you to try Beaver Edge. Keep your hosting. Add the edge layer.

You already deployed the app. The server works. The database works. Your users are using it. Then someone tells you that to get better security, traffic analytics, request logs, or observability you should migrate the whole application somewhere else. That feels backwards. With @vectorihub edge, the application doesn’t move. You connect the domain. vectorihub sits between the internet and your origin. And suddenly the traffic going into an existing deployment becomes something you can actually inspect and control. You can see requests, failures, latency, bandwidth and status codes. You can apply firewall and rate limiting rules. You can understand whether a failure happened at the edge or inside your application. And your server keeps running exactly where it was before. No replatforming. No rebuilding your deployment architecture just to get another infrastructure feature. Connect the domain. Keep your infrastructure. Add the layer you were missing. That’s @vectorihub edge

One of the worst parts of running apps on your own servers is this Something breaks and every layer immediately becomes a suspect. Was it the app? Docker? The reverse proxy? Networking? DNS? The deployment? You can lose 30 minutes just figuring out where to start looking. I’ve been working on removing that ambiguity from @vectorihub Instead of treating traffic as a black box after deployment, vectorihub now tracks what is actually happening at the request level. You can inspect • requests and failures • slow routes • latency • bandwidth • status breakdowns • routers and services • the deployment/container that processed each request The bigger improvement is connecting failures to the layer that caused them. If the app returned an error, vectorihub should say that. If the gateway timed out, rate-limited, or failed before reaching the app, vectorihub should say that too. Raw logs still matter. But raw logs shouldn’t be the first tool you reach for every single time something goes wrong. The platform already has the context. It should use it.

I Shipped something today that's going to make your 2am "why is prod broken" texts a lot less dramatic. Every deploy platform eventually hits the same wall Something's wrong. IDK, check the logs. opens 4,000 lines of raw stdout greps for 20 minutes finds nothing blames DNS That's not debugging. That's log spelunking with a headlamp made of hope. So we rebuilt how @vectorihub shows you what's actually happening. What that actually means: A real traffic dashboard, requests/min, top & slowest endpoints, status breakdown, latency percentiles, bandwidth, live per-container stats Router & service identity attached to every request log, so which container even served this stops being a mystery Automatic failure diagnosis, we tell you if it was your app throwing a 500, or the gateway timing out/rate-limiting/retrying before it ever reached your code Richer log filtering + a summary view, so you're not manually scrolling to find the one request that mattered You don't grep anymore. You don't guess anymore. Somewhere out there, have you tried checking the logs is filing for unemployment right next to EADDRINUSE. You deploy an app and vectorihub tells you, in plain terms, what it's doing and what broke. Same philosophy as always, you shouldn't need to be an SRE to understand your own traffic

Nobody tells you this when you start shipping apps “It's deployed” and “it's working” are two completely different sentences. I ran into this yesterday while working on my deployment platform. A request fails, and suddenly you're SSHing into a VPS, running docker logs, scrolling through output, trying to figure out whether the problem is the request, the container, or the deployment. It made me realize something Deployment visibility shouldn't be a separate problem you solve after deployment. So I spent yesterday building request level observability directly into the platform. Now I can see things like 1. which requests are failing 2. slow endpoints 3. bandwidth 4. which deployment handled the request The interesting part wasn't building another monitoring dashboard. It was realizing how much unnecessary detective work happens after an app is technically deployed.

Nobody tells you this when you start shipping apps, "it's deployed" and "it's working" are two completely different sentences. The gap between them usually looks like this: Something breaks. You SSH in. You run docker logs and watch text scroll by like the Matrix, except instead of finding Neo you find… nothing. Just vibes. 😵‍💫 So today vectorihub stopped making you do detective work with a flashlight and a prayer. Say hello to Request Logs + a full Traffic Dashboard. What you get now: Search any request by path, status, method, container, or deployment (yes, even that one weird request from 3am) Filter by status, duration, time range, or deployment, no more scrolling like it's a group chat Requests per min, slow endpoints, latency, bandwidth, the whole vitals check Click a request, see the exact container's CPU, memory, and restart count at that moment Zero agents to install. It was already watching. A little creepy, mostly useful. You don't grep logs like it's 2009 anymore. You click the red one. Vectorihub tells you exactly which container choked, on what, and how badly. Same philosophy as always: you shouldn't need a whole separate monitoring stack and a coffee, and a small breakdown just to find one bad request. Vectorihub shows you the request, the container, and points at the guilty party like a group project post-mortem.

Shipped something today I'm genuinely excited about. Every deploy tool eventually hits the same wall: "Port already allocated." You redeploy. It fails. You SSH in, hunt for what's holding the port, kill it, try again. 😩 That's not deployment. That's port whack-a-mole. And the mole always wins. So we killed the whole category of bug. @vectorihub now runs its own local reverse proxy on every machine you connect. What that actually means: No more raw ports exposed to the internet Your containers bind to localhost only Vectorihub routes traffic in by domain, not by port Redeploys reuse the same slot automatically Your firewall stays exactly as boring as it should be You don't pick a port anymore. You don't manage a port anymore. Somewhere out there, EADDRINUSE is filing for unemployment. You give vectorihub a domain and it figures out the rest. This is the same philosophy as always: you shouldn't need to think like an infra engineer just to ship an app. Small change under the hood. Big difference the next time you hit deploy.

A question I keep getting "Why @vectorihub ? We already have Kubernetes and GitHub Actions." Fair question. Here's the honest answer, Kubernetes is incredible. It's also like buying a SpaceX starship when you just wanted to get groceries. Powerful? Absolutely. Simple? Not exactly. You don't learn Kubernetes because you want to deploy a small app you learn Kubernetes because Kubernetes became your new full-time job. Then there's GitHub Actions. Amazing tool. But workflows can quietly spiral into: Install this. Configure that. Fix this YAML. Why is indentation breaking production?😭 Many of us have been there. At 2am. Questioning our life choices. The problem isn't that these tools are bad ,they're great at what they do. The problem is that most developers didn't sign up to become infrastructure engineers just to ship software. That's where @vectorihub comes in. Vectorihub focuses on the deployment layer: Connect your infrastructure Deploy your applications Roll back safely Redeploy easily Manage your environments Your servers. Your cloud. Your control. Vectorihub isn't here to replace Kubernetes. It's here for developers who'd rather spend their weekend doing literally anything else than becoming a Kubernetes operator. Sometimes you don't need a spaceship. You just need a reliable car.

It's weird looking back at how @vectorihub started. I never planned to build a deployment platform. I was just frustrated. The kind of frustrated where you start muttering at your terminal like it can hear you. Frustrated by DevOps workflows that felt unnecessarily complicated. Frustrated by containers that failed randomly, confidently, and always at the worst possible moment. Frustrated by watching cloud bills climb like they were training for a marathon while I just tried to keep everything running. Then my friends started asking: "Where can I deploy my app?" The problem? They didn't know Docker. They didn't know Kubernetes. They didn't understand cloud infrastructure. They just wanted their apps online, without first enrolling in a semester of YAML. And honestly, that made sense. Most developers don't dream of becoming infrastructure experts. They want to build products, not spend their weekend googling why a pod is "CrashLoopBackOff" for the fifth time. Somewhere along the way, vectorihub went from "Why is deploying software this painful?" to "How do we make deployment infrastructure disappear?" Today vectorihub is becoming a deployment orchestration layer that helps developers use their own infrastructure without needing a DevOps PhD, a whiteboard, and a good cry. Funny how the things that annoy you the most sometimes become the things you end up building. Still building. Still shipping.