Turning the cloud into a workplace: VPS, Orca, OMP and the `ai-handle` label so agents pick up issues by themselves

Article 17 in the AgentKit v3 onboarding series. About an 8 minute read. Read article 9 and article 13 first.

Lately I rarely have to type prompts. Not because I got lazier, but because work no longer starts with me opening a terminal. A customer reports a bug, the system creates an issue with context, an agent on the VPS picks it up, runs tests, opens a PR, and reports back on Discord. I just review the result.

This article is a guide to rebuilding that loop. To stress it up front: this is how I wire together tools that already exist, not a packaged product. The queue, webhook authentication and the approval step are recommendations, not available out of the box in every setup.

1/ The loop: trigger, handle, verify, report

Customer / Discord / Telegram -> GitHub issue (label ai-handle)
  -> authenticated webhook -> queue -> OMP + AgentKit on the VPS
  -> tests + evidence -> PR -> Discord notification -> a human reviews before merge

The key point is not running on a VPS. The key point is having all four stages: a trigger, an agent that handles it, verification, and reporting.

2/ When to do this

• Your laptop is hot, laggy, and out of disk because of many worktrees and tests running in parallel.

• You want to control agents from your phone without keeping a laptop on 24/7.

• You want issues to become structured input for agents.

• You want a Linux environment closer to production.

Not yet if you do not have a dedicated test repo. And don't assume a VPS is always faster than your home machine: it depends on the real CPU, I/O, network and how much the resources are shared.

3/ Six steps to set it up

Step 1: prepare a dedicated VPS

I am using a VPS of about 40 USD/month, 12 vCPU, 48 GB RAM, 400 GB SSD (price and specs can change, and this is not an uptime guarantee). More important than the specs: don't share it with production. An agent that can run commands and edit code could accidentally break a running service.

Minimum checklist:

• Create a dev user, with sudo limited to what is needed.

• Log in with an SSH key, disable password login (especially for root) after you have tested the key.

• Turn on the firewall, open only the necessary ports, prefer a VPN or Tailscale, keep security updates on.

• Write the recovery procedure in a notes file, and do not write private keys, tokens or passwords in it.

Changing the SSH port only reduces automated scanning; it does not replace keys and a firewall.

Step 2: Orca to control it from Mac and iPhone

Orca is an Agent IDE with desktop, mobile and a headless server mode. Per the Orca docs at the time of the original post, on Linux the CLI command is usually named orca-ide (not orca, a name that can collide with the GNOME screen reader):

orca-ide status --json
orca-ide serve --pairing-address <TAILSCALE_IP> --mobile-pairing

Treat the orca://pair?... pairing link like a password: don't commit it, don't paste it into public chats. Don't expose the remote port to the internet unless you have to. Orca's command flags may change between versions, so check the Orca docs.

Step 3: install OMP and AgentKit

On the VPS, install Oh My Pi (OMP) as the agent runtime and AgentKit per agentkit.best/docs.md. Do the login part by hand:

ssh dev@<VPS_IP>
omp                       # log in to the AI provider yourself in a separate session
ak login --api-key <YOUR_AK_KEY>
ak kit init engineer --target omp -g -y

Do not paste real keys into prompts, issues, logs or Markdown files. See also article 6 and article 4 for installing kits per runtime.

Step 4: connect a GitHub webhook to the agent

Use the ai-handle label to turn an issue into structured input. When an issues.labeled event with the ai-handle label happens, the webhook triggers OMP on the VPS to run the /ak:vibe --advice --ship --beta workflow (in v3 it is /ak-vibe), then reports the result via Discord.

Protection layers you should definitely have, because an issue is untrusted data:

• Verify the HMAC SHA-256 signature in the X-Hub-Signature-256 header before accepting the job.

• Verify the right repository, the right action, the right label.

• Prevent duplicate runs (each delivery creates only one job).

• Limit the number of jobs and the run time.

• The Discord webhook URL is a secret, keep it out of prompts and logs.

• Only run on allowed repos; no auto-merge, no auto-deploy. Let the agent open a PR first, and a human reviews before merging.

One part has to be done by hand in GitHub Settings: adding the webhook, the secret and the authentication permissions.

Step 5: test with a harmless issue

Create a small issue like "update the README", label it ai-handle, then check:

• A valid webhook is accepted, a wrong signature is rejected.

• The right repo, the right issue, the right label.

• The agent runs in its own worktree, with a timeout.

• There are passing tests, a commit link, a PR and a Discord notification.

• Nothing touches production.

Step 6: let an agent take bug reports from customers

I have a Dewee agent on Discord: a customer reports a bug, the agent looks through the source, does a preliminary verification, then creates an issue with enough information and applies ai-handle. A customer request still has to be classified, permission-limited and checked before it becomes a write action. Customer data must never become arbitrary commands.

4/ Status by part

Wrap-up

1/ Start with one dedicated VPS, one test repo, one ai-handle label, one README task. Get one loop right before expanding.

2/ The webhook must verify signatures. An issue is untrusted data.

3/ The agent opens a PR, a human reviews before merging.

4/ Running does not mean safe. Running for a long time does not mean stable.

Sources

• Turn the cloud environment into a workplace: let AI agents pick up and handle work 24/7 (10/10/2026)

• Orca: remote servers and mobile pairing

• GitHub: validating webhook deliveries