Run the Apus Gateway on any Linux server or cloud VPS. This page helps you pick a provider, explains how cloud deployments work, and covers generic Linux tuning that applies everywhere.

Pick a provider

AWS (EC2 / Lightsail / free tier) also works well. A community video walkthrough is available at x.com/techfrenAJ/status/2014934471095812547 (community resource -- may become unavailable).

How cloud setups work

• The Gateway runs on the VPS and owns state + workspace.
• You connect from your laptop or phone via the Control UI or Tailscale/SSH.
• Treat the VPS as the source of truth and back up the state + workspace regularly.
• Secure default: keep the Gateway on loopback and access it via SSH tunnel or Tailscale Serve. If you bind to lan or tailnet, the Gateway requires a shared secret (gateway.auth.token or gateway.auth.password) unless auth is delegated to a trusted proxy.

Related pages: Gateway remote access, Platforms hub.

Harden admin access first

Before you install Apus on a public VPS, decide how you want to administer the box itself.

• For Tailnet-only admin access: install Tailscale first, join the VPS to your tailnet, verify a second SSH session over the Tailscale IP or MagicDNS name, then restrict public SSH.
• Without Tailscale: apply the equivalent hardening for your SSH path before exposing more services.
• This is separate from Gateway access. You can still keep Apus bound to loopback and use an SSH tunnel or Tailscale Serve for the dashboard.

Tailscale-specific Gateway options live in Tailscale.

Shared company agent on a VPS

Running a single agent for a team is a valid setup when every user is in the same trust boundary and the agent is business-only.

• Keep it on a dedicated runtime (VPS/VM/container + dedicated OS user/accounts).
• Do not sign that runtime into personal Apple/Google accounts or personal browser/password-manager profiles.
• If users are adversarial to each other, split by gateway/host/OS user.

Security model details: Security.

Using nodes with a VPS

You can keep the Gateway in the cloud and pair nodes on your local devices (Mac/iOS/Android/headless). Nodes provide local screen/camera and system.run capabilities while the Gateway stays in the cloud. A paired Mac can also present hosted widgets in its native panel.

Docs: Nodes, Nodes CLI.

Startup tuning for small VMs and ARM hosts

If CLI commands feel slow on low-power VMs (or ARM hosts), enable Node's module compile cache:

grep -q 'NODE_COMPILE_CACHE=/var/tmp/apus-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
export NODE_COMPILE_CACHE=/var/tmp/apus-compile-cache
mkdir -p /var/tmp/apus-compile-cache
export APUS_NO_RESPAWN=1
EOF
source ~/.bashrc

• NODE_COMPILE_CACHE improves repeated command startup times; the first run warms the cache.
• APUS_NO_RESPAWN=1 keeps routine Gateway restarts in-process, which avoids extra process handoffs and keeps PID tracking simple on small hosts.
• For Raspberry Pi specifics, see Raspberry Pi.

systemd tuning checklist (optional)

For VM hosts using systemd, consider:

• Service env for a stable startup path: APUS_NO_RESPAWN=1 and NODE_COMPILE_CACHE=/var/tmp/apus-compile-cache
• A longer startup timeout for slow hosts: TimeoutStartSec=90.
• The managed unit owns the generic restart policy: Restart=always, RestartSec=5.
• SSD-backed disks for state/cache paths to reduce random-I/O cold-start penalties.

The standard apus onboard --install-daemon path installs a systemd user unit; customize only host-specific startup settings with:

systemctl --user edit apus-gateway.service

[Service]
Environment=APUS_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/apus-compile-cache
TimeoutStartSec=90

If you deliberately installed a system unit instead, edit it via sudo systemctl edit apus-gateway.service.

For the canonical managed unit body and its restart policy, see the Gateway runbook.

For Linux OOM behavior, child process victim selection, and exit 137 diagnostics, see Linux memory pressure and OOM kills.

Related

• Install overview
• DigitalOcean
• Fly.io
• Hetzner
• Ansible — automated deployment to remote Debian/Ubuntu servers with Tailscale VPN and firewall isolation
• Kubernetes — a minimal Kustomize starting point when you run the Gateway on a cluster instead of a single VPS
• macOS VMs — a sandboxed macOS VM when you need macOS itself (iMessage) rather than a Linux host