VM / Server Hosting · GitHub Copilot Best Practices

Key insight: A laptop is fine for most OpenCode use cases, but some workflows need to run 24/7 — bots that listen for messages, daily digest jobs, scheduled syncs. A VM inside your organisation's infrastructure gives you that without any external cloud cost.

When a VM makes sense

If any of these apply to what you're building, a VM is the right host:

Bots and listeners — Webex bots, webhook receivers, anything that needs to stay connected and respond to events around the clock
Scheduled jobs — daily briefings, overnight syncs, cron-driven reports that run whether or not your laptop is open
Persistent processes — long-running scripts, background monitors, queue workers
Shared team automation — services that shouldn't depend on one person's machine or VPN session
Heavier workloads — tasks that would slow your laptop or need dedicated resources

If your workflow is interactive — you run it, you wait for a result, you're done — a laptop is fine. A VM is for the things that need to keep running after you close the lid.

Getting a VM

How you get a VM depends on your organisation. Common options include cloud providers (AWS, Azure, GCP), internal IT provisioning portals, or self-hosted infrastructure. Aim for at least 2 vCPUs, 4–8 GB RAM, and 50+ GB disk. Ubuntu 24.04 LTS is a solid default OS choice.

Once provisioned, IT or your cloud console will give you the VM's IP address and initial credentials.

Connecting to your VM via SSH

SSH (Secure Shell) is the standard way to connect to and control a remote server from your terminal. It opens a secure, encrypted command-line session on the VM — everything you type runs on the VM, not your local machine.

Rather than following manual setup steps, just ask your agentic app to do it for you:

Prompt to use: "Help me set up an SSH connection to my VM. The IP address is [your VM IP] and my username is [your username]. Generate an SSH key if I don't have one, copy it to the VM, and confirm passwordless login works."

OpenCode (or any agentic tool with terminal access) can handle key generation, copying the public key to the VM, and testing the connection end to end.

The working model — laptop for development, VM for services

Once your VM is running, treat the two machines as having distinct roles:

Your laptop: Development — write code, run OpenCode desktop, manage your backlog
The VM: Production — run services 24/7 (bots, scheduled jobs, monitors)

Your code lives in a GitHub repo. You develop on your laptop and push changes; the VM pulls from the same repo to deploy updates. Neither machine is "the original" — the repo is the source of truth.

GitHub repo
        ↑ git push              ↑ git pull
   Your laptop                 The VM
  (write code here)       (runs services 24/7)

See File Management for the full Git workflow.