Hiren Kalariya

Posted on Sep 18

Building a Local-First DevOps Workflow Without Cloud Sync

#devops #security #ssh #productivity

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.

DEV Community