DEV Community: Hiren Kalariya

Building a Local-First DevOps Workflow Without Cloud Sync

Hiren Kalariya — Fri, 18 Sep 2026 10:58:38 +0000

You just finished a 14-hour sprint. Pushed code, configured Nginx, set up SSL. Everything runs. You close your laptop.

Three weeks later, your cloud-synced SSH client sends you a breach notification email. Someone accessed your vault. Every server credential you stored - production databases, client staging environments, root keys - is potentially exposed.

The fix isn't more encryption on top of cloud sync. The fix is removing the sync entirely.

This article walks through building a complete local-first DevOps workflow - from SSH management to deployment to monitoring - where your credentials never leave your machine.

Why Cloud-Synced DevOps Tools Are a Liability

Most developers don't think about where their SSH keys live. They paste credentials into Termius, 1Password, or a shared team vault. It "just works." Until it doesn't.

Here's the problem: every cloud-synced credential is a liability sitting on infrastructure you don't control.

The attack surface math is simple:

Your local machine = 1 target
Cloud vault + transit + backup + CDN edge nodes = dozens of targets
Add team members syncing across devices = hundreds of targets

The 2026 DevOps Threats Report documented 68 AI-related security incidents across DevOps platforms in a single year.

Credential theft showed steady month-over-month increases, with secret leaks going undetected before escalating into incidents affecting multiple repositories.

IBM's Cost of a Data Breach data puts the global average at $4.44M per breach, with stolen credentials consistently among the most expensive attack vectors, often exceeding $5M because they take the longest to detect.

Cloud sync isn't inherently evil. But for server credentials and SSH keys? The risk-reward ratio is upside down.

What "Local-First" Actually Means (And What It Doesn't)

Local-first doesn't mean offline-only. It doesn't mean anti-cloud. It means one principle: your sensitive data stays on your machine unless you explicitly decide otherwise.

Here's the difference:

Aspect	Cloud-First Approach	Local-First Approach
Credential storage	Encrypted vault on provider's servers	Encrypted on your local filesystem
SSH keys	Synced across devices via cloud	Generated and stored per-machine
Deployment scripts	Stored in SaaS dashboard	Local scripts executed over SSH
Server inventory	Cloud-hosted dashboard	Local app or config file
Breach surface	Every synced device + cloud infra	Only your physical machine

Local-first means you SSH into servers directly, manage credentials locally, and run deployments from your own machine - not through a SaaS middleman.

The trade-off? You lose cross-device sync. You can't pull up server credentials on your phone at dinner. That's the point. Server management isn't a mobile activity.

Step 1: Set Up SSH Key Management Without Cloud Sync

The foundation of any local-first workflow is SSH key management. Here's the manual approach most developers use:

Generate a dedicated key per server (or per client)

ssh-keygen -t ed25519 -C "yourname@project-staging" -f ~/.ssh/project_staging_key

Configure your SSH config file

# ~/.ssh/config
Host project-staging
    HostName 165.22.xx.xx
    User deploy
    IdentityFile ~/.ssh/project_staging_key
    IdentitiesOnly yes

Host project-production
    HostName 164.90.xx.xx
    User deploy
    IdentityFile ~/.ssh/project_production_key
    IdentitiesOnly yes

Lock down permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/project_staging_key
chmod 644 ~/.ssh/project_staging_key.pub

Time estimate for manual setup: 15–20 minutes per server, including key generation, copying the public key, testing the connection, and updating your config.

For 10 servers, that's 2.5–3 hours of setup. For 25 servers across multiple clients? A full day.

The faster path

Tools like CtrlOps handle this through a visual SSH setup wizard. You paste a server IP, select your authentication method, and the tool generates and stores the key locally - never syncing it anywhere. The connection is saved as a named host you can click to connect.

No cloud. No vault. No sync. Just a local app that remembers your servers.

If you're currently using a cloud-synced SSH client and want to understand the alternatives, these Termius alternatives break down how different tools handle credential storage - cloud vs. local.

Step 2: Build Your Server Inventory Locally

The spreadsheet problem is real. Most small teams track server IPs, usernames, ports, and key paths in a Google Sheet or a Notion page. That's credentials in plaintext, synced to the cloud, shared via link.

The manual method

Create a local inventory file:

# ~/servers/inventory.yml
staging:
  host: 165.22.xx.xx
  user: deploy
  key: ~/.ssh/project_staging_key
  services: [nginx, node, pm2]
  last_updated: 2026-09-15

production:
  host: 164.90.xx.xx
  user: deploy
  key: ~/.ssh/project_production_key
  services: [nginx, node, pm2, redis]
  last_updated: 2026-09-15

Encrypt it with GPG:

gpg --symmetric --cipher-algo AES256 ~/servers/inventory.yml
# Delete the plaintext version
rm ~/servers/inventory.yml

Time estimate: 30 minutes for initial setup, plus 5 minutes per server added.

The problem: You now have an encrypted file you need to decrypt every time you want to connect to a server. That friction adds up - fast.

The local-app approach

A desktop app like CtrlOps replaces the spreadsheet entirely. Servers appear as named cards on a visual dashboard - one click to connect. The data is stored locally on your machine's filesystem. No cloud dashboard, no shared links, no encrypted YAML to wrestle with.

The practical difference: a spreadsheet takes 3–5 minutes of copy-pasting IPs and keys before you can SSH in. A local server directory takes one click.

Step 3: Deploy Applications Without a Cloud Dashboard

Most deployment tools today - Forge, RunCloud, Ploi - run as cloud SaaS. They install agents on your servers, sync your config to their dashboards, and process deployments through their infrastructure.

That's fine for teams who trust that model. But it means your deployment credentials, environment variables, and server configs live on someone else's infrastructure.

The manual deployment workflow

Here's what a local-first deployment looks like with raw SSH:

# 1. SSH into the server
ssh project-production

# 2. Navigate to the app directory
cd /var/www/myapp

# 3. Pull the latest code
git pull origin main

# 4. Install dependencies
npm install --production

# 5. Run database migrations
npx prisma migrate deploy

# 6. Restart the process manager
pm2 restart myapp

# 7. Verify it's running
pm2 status
curl -I https://myapp.com

Time estimate: 15–25 minutes per server, depending on build times and migration complexity. For multi-server deployments, multiply accordingly.

The local-first shortcut

CtrlOps wraps this into a guided deployment flow. You select a server, paste a GitHub repo URL, pick a runtime (Node.js, Python, etc.), add your environment variables, toggle SSL, and hit deploy. The entire process runs over your existing SSH connection - no agent installed on the server, no cloud relay.

Deployment time drops from 25 minutes of terminal work to about 5 minutes of form-filling. The .env values never leave your machine. The deployment runs over the same SSH tunnel you'd use manually.

Worth noting: Local-first deployment tools aren't for everyone. If you need CI/CD pipelines, multi-region rollouts, or container orchestration, you'll want a different toolchain. Local-first works best for direct server deployments on VPS/bare metal.

Step 4: Monitor Infrastructure Without Shipping Data Out

Traditional monitoring means installing agents (Datadog, New Relic, Grafana Cloud) that ship your server metrics to external dashboards. That's powerful for large-scale operations. But for a freelancer managing 8 client servers or a startup running 3 VPS instances? It's overkill - and it means your server performance data lives in yet another cloud.

The manual monitoring commands

# CPU and memory
top -bn1 | head -20

# Disk usage
df -h

# Memory details
free -m

# Active connections
ss -tuln

# Recent error logs
tail -50 /var/log/nginx/error.log

Time estimate: 5–10 minutes per server per check. Across 5 servers, daily monitoring eats 30–50 minutes.

The local-first alternative

CtrlOps shows a real-time infrastructure dashboard - CPU, RAM, disk, network - pulled directly over your SSH connection. No agent installed. No data shipped to a third party. The metrics exist only in the app on your machine.

This doesn't replace Datadog for a 50-server fleet. But for small teams, it replaces 30 minutes of daily SSH-and-grep with a single dashboard view.

Step 5: Use AI for Diagnostics Without Sending Context to Third Parties

Here's where things get interesting. AI-powered server diagnostics are genuinely useful - "why is my server slow?" beats manually running top, iostat, netstat, and reading through logs.

But most AI terminal tools route your queries (and your server context) through their own API. Your server output, your error logs, your config files - all hitting a third-party endpoint.

The local-first AI approach

CtrlOps uses a BYOK (Bring Your Own Key) model for its AI terminal. You connect your own OpenAI, Anthropic, Google Gemini, or any OpenAI-compatible API key. Queries go directly from your machine to the AI provider - not through CtrlOps's servers.

The critical part: every AI-generated command goes through an approval gate. The AI suggests systemctl restart nginx. You see the command. You click Run. The command executes over SSH.

No blind execution. No intermediate cloud. Your API key, your model, your control.

You: "Why is my server slow?"

AI: Based on the current server stats, here's what I found:
    - CPU usage at 94% - 3 Node.js processes consuming most resources
    - Memory at 87% - Redis cache appears to have grown significantly

    Suggested commands:
    1. pm2 restart all          [Run]
    2. redis-cli FLUSHDB        [Run]
    3. journalctl -u nginx -n 50  [Run]

Each command is shown before execution. You approve one at a time.

The Full Local-First DevOps Stack

Here's what a complete local-first workflow looks like, assembled from the steps above:

Layer	Cloud-Synced Approach	Local-First Approach
SSH client	Termius (cloud vault)	CtrlOps or SSH config (local-only)
Server inventory	Notion / Google Sheet	Local app or encrypted YAML
Deployment	Forge / RunCloud (cloud SaaS)	CtrlOps or SSH scripts (direct)
Monitoring	Datadog / New Relic (agent + cloud)	CtrlOps infra dashboard (over SSH)
AI diagnostics	Warp (cloud-required)	CtrlOps AI terminal (BYOK, local)
File management	SFTP via FileZilla	CtrlOps file manager or `scp`
Credential storage	1Password / Termius vault	Local keychain / local app

Total cost comparison:

Cloud-synced stack (Termius Pro + Forge + Datadog): $50–150+/month
Local-first stack with CtrlOps: $7/month per user

If you're exploring which SSH tools fit this workflow, this comparison of PuTTY, Webmin, and ServerPilot alternatives covers the full spectrum from legacy tools to modern local-first options.

When Local-First Doesn't Make Sense

Let's be honest about the trade-offs.

You probably need cloud-synced tools if:

Your team spans 20+ people who need shared credential access
You manage Kubernetes clusters or serverless functions
You need SOC2 Type II compliance with audit trails
You require mobile access to server management
Your infrastructure is multi-region with complex orchestration

Local-first works best when:

You're a freelancer managing client servers
You're a small team (2–10 devs) on VPS or bare metal
Security and data sovereignty are non-negotiable
You want to stop paying per-user pricing for server access
You manage 5–50 servers that don't need container orchestration

The honest answer: most indie developers and small startups fall into the second category. But if you're running infrastructure at scale, cloud-native tools earn their complexity.

Getting Started: A 30-Minute Migration Plan

If you're ready to move from cloud-synced to local-first, here's a realistic migration path:

Minutes 1–5: Download CtrlOps (macOS, Windows, or Linux). It's free for 1 month, no credit card.

Minutes 5–15: Import your servers. If you're coming from Termius, CtrlOps has a one-step import that moves hosts, ports, usernames, and keys locally in about 30 seconds. From other tools, add servers manually - it takes about 2 minutes per server.

Minutes 15–25: Test connections. Click each server card, verify the SSH connection works, and check the infra dashboard loads.

Minutes 25–30: Set up the AI terminal (optional). Paste your OpenAI or Anthropic API key. Run a test query like "check disk space" to verify it works.

That's it. Your credentials are now local-only. Your servers are managed from your machine. No cloud vault standing between you and your infrastructure.

Wrapping Up

The DevOps industry has defaulted to cloud-first for everything, including tools that handle your most sensitive data. SSH keys, server credentials, environment variables - these aren't files that benefit from cloud sync. They benefit from staying exactly where they are: on your machine.

Local-first isn't about rejecting the cloud. It's about choosing which data deserves cloud convenience and which data deserves local control.

Your deployment configs and server credentials fall firmly in the second category.

If you're managing servers across multiple clients and want a starting point, check which SSH tools actually keep credentials local; the differences are bigger than you'd expect.

Termius Alternatives in 2026: What I Learned Testing 6 SSH Clients

Hiren Kalariya — Thu, 13 Aug 2026 12:17:16 +0000

Last month, our staging server threw a 502. I had Termius open, connected to the right box, and started debugging. Fifteen minutes in, I realised I was copying error messages into ChatGPT in a separate browser tab, pasting commands back, and praying I didn't mix up which terminal tab was staging vs. production.

That moment made me question whether my SSH setup was actually helping me or just giving me a familiar place to be slow.

So I spent two weeks testing 6 SSH clients against three real tasks every developer recognises:

Deploy a Node.js app to a fresh VPS
Debug a down service at odd hours
Manage 10+ servers without losing track

Here's what I found.

The 6 tools I tested

CtrlOps

Type: SSH + server management
Price: $7/mo
Platform: Mac, Windows, Linux

Termius

Type: SSH client + cloud sync
Price: Free / $10/mo Pro
Platform: All, including mobile

Tabby

Type: Open-source terminal
Price: Free
Platform: Mac, Windows, Linux

iTerm2

Type: Terminal emulator
Price: Free
Platform: Mac only

MobaXterm

Type: Multi-protocol toolkit
Price: Free / $69 one-time
Platform: Windows only

OpenSSH

Type: CLI (built-in)
Price: Free
Platform: Everywhere

I'm including CtrlOps because I built it and can speak honestly to its design decisions. I'll call out where it falls short, too.

Test 1: Deploy a Node.js app to a fresh Ubuntu VPS

This is the task that separates "SSH client" from "server management tool." Every tool can connect to a server. The question is what happens after you connect.

With OpenSSH + manual commands, the full sequence is: SSH in, install Node, install PM2, clone repo, set up .env, configure Nginx, run Certbot for SSL, start the process. I timed myself at 28 minutes, and I've done this hundreds of times.

Termius made the connection instant (saved credentials, one click). But the deployment itself was still manual. Termius is an excellent SSH client. It is not a deployment tool.

Total: 25 minutes.

CtrlOps has a guided deployment flow. Paste the GitHub URL, pick Node.js, add env vars, toggle SSL on, hit Create. It ran the same commands I'd type: clone, npm install, PM2, Nginx, Certbot manually, but showed each one for approval before executing.

Total: 5 minutes.

What I learned: For pure SSH, Termius is polished. If you deploy apps regularly, a tool that automates the full sequence (with a review step) saves 20+ minutes each time.

If you're curious about how AI is changing deployment workflows more broadly, I wrote about it here: How AI is Reshaping DevOps in 2026.

Test 2: Debug a service that's down

I simulated a common scenario: a Node.js app returning 502, the PM2 process crashed, disk was at 91%.

OpenSSH: I had to remember the commands. pm2 status, journalctl -u nginx, df -h, free -m. If you know Linux well, this works. If you're a developer who manages servers as a side responsibility, you're Googling half of these.

iTerm2 and Tabby gave me a better terminal experience (tabs, split panes, search through output) but didn't change the debugging workflow. The commands were the same.

Termius had snippets I'd saved from previous incidents, which helped. Its SFTP browser let me check config files without cat and nano. Solid.

CtrlOps uses a built-in AI assistant to help you diagnose issues. You can type your question in natural language (e.g., "why is my app returning 502") to get diagnostic commands. The key differentiator is safety: every command is generated with an explicit "Run" button and a detailed explanation of what it does, so nothing runs automatically on your server. After running, the AI summarizes the output in plain English: "PM2 process 'api' crashed 3 times in the last hour. Disk usage is at 91%. The most recent error log shows ENOSPC: no space available." That summary saved me from reading through 200 lines of logs.

What I learned: For debugging, what matters most is whether the tool helps you understand what's wrong, not just run commands. CtrlOps leverages AI to translate raw logs and command outputs into plain-English feedback.

How do AI Terminals compare in action?
We tested Termius AI, Kiro CLI, and CtrlOps for server management. See which AI terminal keeps servers clean with approval-gated, desktop-first automation. Watch the full comparison here:
Watch the comparison on YouTube

Test 3: Manage 10+ servers without losing track

This test is personal. At CtrlOps, we manage staging and production for multiple projects. Before building our own tool, I used a combination of Termius (for saved hosts) and a Notion table (for "which server runs what").

OpenSSH with ~/.ssh/config works if you maintain it. I've seen teams where the config file is 200+ lines, and nobody remembers which alias maps to which project. It's free and powerful, but it's a text file: no visual feedback, no grouping, no status at a glance.

Termius handles this the best among traditional SSH clients. Groups, tags, colour coding, search. If your main need is "connect to the right server fast," Termius is excellent. Its cloud sync means the same server list across your laptop, phone, and tablet.

For teams, the shared vault is a real collaboration feature.

One thing to consider: Termius syncs your credentials through their cloud (encrypted end-to-end). For most teams, that's fine and very convenient. For teams whose clients or compliance requirements prohibit cloud-stored credentials, it's a blocker.

MobaXterm surprised me here. Its session manager with folders and tabbed sessions handles large server lists well. The embedded X11 server and multi-protocol support (RDP, VNC, SSH in one app) make it a legitimate all-in-one for Windows admins. The limitation is obvious: Windows only.

CtrlOps stores everything locally. No cloud sync. You organise servers by name, and each one shows a live status indicator. The upside is you know your credentials never leave your machine. The downside is real: if you switch between a desktop and a laptop, you'll re-add servers manually (or export/import). No mobile app either.

Where CtrlOps diverges from the group: it shows CPU, memory, and disk usage per server without opening a terminal. When you have 10+ servers, scanning a dashboard beats SSH-ing into each one and running htop.

I wrote a longer piece on multi-server workflows here: Managing Multiple Servers Without Losing Control.

Important feature: Server Security Auditing & Hardening

One feature that set CtrlOps completely apart from traditional SSH clients during my testing was its new Security Audit module.

While tools like Termius or MobaXterm focus purely on connection and terminal management, CtrlOps allows you to run 25 predefined configuration audits on a connected Linux server over SSH without installing any agent or writing custom scripts:

Multi-Category Audits: It checks Server configuration (SSH, firewall, updates), Databases (MySQL, PostgreSQL, MongoDB, Redis hardening), Docker environments, and Web Servers (Nginx/Apache security headers, TLS configuration).
Hardening Score & PDF Reports: It scans the server and returns a hardening score with a breakdown of passed, failed, and skipped checks. You can export this as a clean PDF report to share with clients or team members.
AI-Powered Mitigation: If an audit fails (e.g., weak SSH configuration or missing firewall rules), you can select the findings and click "Fix selected findings". This copies a mitigation prompt to your clipboard. When pasted into CtrlOps' AI Terminal, the assistant generates the exact fix commands with a detailed explanation and waits for your approval before executing them.

For developers who manage client servers or production environments, having security scanning built directly into the client is a huge time-saver.

The honest trade-off

No tool wins everything. Here's where each one earned my respect and where it didn't.

Termius

Best at: Cross-device sync, mobile access, team vaults
Weakest at: No deployment automation, no infrastructure monitoring

Tabby

Best at: Open-source, customizable, serial/SSH in one
Weakest at: No AI, no deployment features

iTerm2

Best at: Mac terminal experience, split panes, search
Weakest at: Mac only, no SSH management features

MobaXterm

Best at: Multi-protocol (RDP + SSH + VNC), free tier
Weakest at: Windows only, no AI, dated UI

OpenSSH

Best at: Zero dependencies, works everywhere
Weakest at: No GUI, no saved sessions without config, no AI

CtrlOps

Best at: Deployment automation, AI with approval, monitoring, security auditing
Weakest at: No mobile app, no cloud sync

What I'd recommend based on your workflow

If you mostly code locally and SSH in occasionally, use iTerm2 (on Mac) or Tabby (on Windows/Linux).

You want a great terminal, not a server management platform.

If you manage servers across devices, including your phone, use Termius.

Nothing else matches its cross-platform reach.

If you're a Windows admin juggling SSH, RDP, and VNC, use MobaXterm.

One tool to cover all protocols.

If you deploy, monitor, and secure apps on VPS, use CtrlOps.

That's the specific workflow we built for. The combination of deployment automation, AI diagnosis with approval gates, and built-in security auditing makes it a complete control center. But know the trade-offs: no mobile, no port forwarding, no Kubernetes.

If you want free and open-source, Tabby for a modern experience, OpenSSH if you're comfortable in a bare terminal.

For a more detailed Termius alternatives breakdown, we compared each in depth here: 9 Best Termius Alternatives in 2026.

What surprised me most

Two things stood out from this whole exercise:

1. The "SSH client" category has split in two

Some tools help you connect to servers (Termius, PuTTY, iTerm2) and tools that help you manage servers (like CtrlOps). These solve different problems. Comparing them on the same checklist misses the point.

2. AI in the terminal is only useful if you trust it

In our testing of AI terminals (including Termius AI and Kiro CLI), we saw that fully autonomous auto-running tools can be risky in production. CtrlOps shows commands for approval, which is slower but safer. The right choice depends on whether the server you're touching is a dev sandbox or a client's production box.

Final Thought

The SSH client you pick matters less than whether it fits the job you're doing. A freelancer managing 3 client VPSes has completely different needs than a platform engineer working with Kubernetes clusters.

Pick the tool that matches your actual workflow, not the one with the longest feature list.