Your First Remote Orca Workspace on a Free-Tier VM with Infisical

Running four coding agents in local git worktrees feels great—right up until four language servers and four pnpm test runs eat 16 GB of laptop RAM. Moving your workspace to a free-tier Linux VM stops the fan noise, but you hit two traps immediately. First, 1 GB free-tier VMs run out of memory just compiling native terminal modules or running parallel builds [INFERENCE]. Second, copying .env files into every new worktree scatters plaintext credentials across a remote disk where agents run with permission prompts bypassed by default.

On November 2, 2026, we checked the Orca documentation and source repository (stablyai/orca), Infisical’s CLI and Agent Proxy docs, and the current free-tier rules for Oracle Cloud, AWS, Google Cloud, and GitHub Codespaces. If you are an engineer or architect setting up a remote agentic workspace, this guide walks you through picking a free-tier VM that will not OOM, wiring orca.yaml, and replacing .env copying with Infisical Machine Identities and Linux bubblewrap sandboxing. For secret rotation and macOS trust roots, see Keep Secrets Out of the Agent. For multi-repo cloud fleets, see Running Agentic Workspaces in the Cloud at Scale.

TL;DR

• Pick the right free-tier VM: As of November 2, 2026, Oracle Cloud’s Always Free VM.Standard.A1.Flex (aarch64) gives up to 2 OCPUs and 12 GB RAM continuous (1,500 OCPU-hours and 9,000 GB-hours per month) plus 200 GB of block storage. Oracle halved that cap from 4 OCPUs / 24 GB RAM on June 15, 2026, and older 4/24 instances cannot be recreated above 2/12 if terminated. Even at 12 GB, it is the only zero-dollar, always-on tier here that runs parallel worktrees without swap thrashing [INFERENCE].
• Know how Orca creates remote worktrees: Orca offers an SSH Target mode (Settings → SSH) and a Remote Orca Server mode (orca-ide serve). As of November 2026, worktrees created by orca-ide serve on the VM apply worktree.sharedDirectories and .worktreeinclude. SSH Target worktrees skip both and rely on scripts.setup in orca.yaml.
• Do not copy .env across worktrees: Orca starts coding agents with permission-bypass flags by default. Git worktrees isolate files, not processes or credentials. Putting .env in .worktreeinclude or copying it in scripts.setup exposes raw secrets to every agent session [INFERENCE].
• Split test runs from agent sessions: Authenticate the VM with a dev-scoped Infisical Machine Identity (universal-auth, aws-iam, or gcp-id-token). Run one-shot app tests with infisical sm run in a separate terminal tab after reviewing diffs. Launch coding agents inside infisical sm agent-proxy run so bubblewrap (bwrap) blocks direct network access and attaches HTTP(S) credentials in flight.

1. Choosing a Free-Tier VM That Will Not OOM

A coding agent CLI such as Claude Code or Codex sends inference over the network, so it needs no GPU. Memory and disk I/O are the real bottlenecks. A remote VM has to compile native terminal modules on first connect, hold multiple git worktrees on disk, and run package managers or test runners in parallel [INFERENCE].

Cloud providers changed several free tiers between July 2025 and June 2026. We checked every quota below against official vendor docs on November 2, 2026, though cloud providers can change them without notice.

Before you create an Oracle Arm instance, check Governance → Limits, Quotas and Usage in the OCI Console to verify your tenancy’s VM.Standard.A1.Flex limit (Oracle Cloud Always Free Resources, accessed 2026-11-02). Watch out for two OCI quirks:

• Capacity vs. Pay As You Go: Free Tier tenancies often hit Out of host capacity errors on Arm A1 shapes. Upgrading to Pay As You Go (PAYG) opens standard capacity pools and costs $0 USD if you stay within Always Free limits [INFERENCE].
• The 7-day idle rule: On a 12 GB Arm VM, 20% memory is ~2.4 GB. If the VM sits below 20% P95 CPU, network, and memory for 7 days, Oracle can stop the instance. Your boot volume stays intact so you can start it again later.

2. Two Ways to Connect Orca to Your Linux VM

Orca supports four execution modes: local checkouts, SSH Targets, Remote Orca Servers, and an experimental per-workspace Cloud VM mode (environmentRecipes in orca.yaml, marked experimental as of November 2026) (Ways to run Orca, accessed 2026-11-02). For a single free-tier VM, you will use either an SSH Target or a Remote Orca Server.

Which mode should you pick? Pick Mode B (orca-ide serve) on an always-on 12 GB OCI Arm VM. It gives you automatic worktree.sharedDirectories symlinking, per-terminal systemd memory caps, and sessions that survive laptop sleep [INFERENCE]. Pick Mode A (SSH Target) on a 1–2 GB VM or when you do not want Tailscale. In Mode A, your laptop runs the heavier desktop runtime while the VM runs only the ~/.orca-remote/ daemon [INFERENCE].

Pay close attention to the .worktreeinclude row in the table above. As of November 2026, .worktreeinclude (PR #9791) and worktree.sharedDirectories (PR #10459) run only during local worktree creation (orca.yaml reference, accessed 2026-11-02). Under orca-ide serve, worktrees are local to the VM runtime, so both features work out of the box [INFERENCE]. Under SSH Target mode, remote worktree creation skips both and relies on scripts.setup instead.

Bootstrapping the Linux VM for Both Modes

Install the packages that Orca and Infisical’s sandbox need on Ubuntu 22.04 or 24.04 (x86_64 or aarch64):

sudo apt-get update && sudo apt-get install -y \
  build-essential python3 git curl jq file xvfb zlib1g-dev bubblewrap

Here is why you need each package group:

• build-essential (make, g++) and python3: Required for SSH Target mode. On first connect, Orca installs orcad under ~/.orca-remote/ and compiles the native node-pty module (SSH worktrees, accessed 2026-11-02). Without them, Git and file edits work, but remote terminals fail to open. On a 1 GB VM (e2-micro), add a 2 GB swapfile first so g++ does not OOM [INFERENCE].
• bubblewrap (bwrap): Required on Linux by infisical sm agent-proxy run to sandbox coding agents (Infisical local Agent Proxy, accessed 2026-11-02).
• file, jq, xvfb, zlib1g-dev: Needed for headless Linux server mode (Headless Linux Server reference, accessed 2026-11-02). On Ubuntu or Debian, installing the .deb release (sudo apt install ./orca-ide_<version>_arm64.deb) pulls in any remaining shared libraries and puts /usr/bin/orca-ide on PATH.

Running Mode B: orca-ide serve with Per-Terminal Memory Caps

On Linux, Orca names its CLI binary orca-ide because /usr/bin/orca belongs to the GNOME screen reader (Install Orca, accessed 2026-11-02). Inside an Orca terminal, Orca adds an orca shim to PATH, and orca-ide serve writes ~/.local/bin/orca at startup.

To stop a runaway build from freezing the whole VM, enable systemd user linger and set ORCA_TERMINAL_MEMORY_MAX (minimum 256M) and ORCA_TERMINAL_MEMORY_SWAP_MAX (0 disables swap) before starting orca-ide serve. With systemd and cgroup v2 active, Orca isolates each terminal in a transient user scope so the Linux OOM killer only kills that terminal’s process (Remote Orca Servers and Issue #28320, accessed 2026-11-02):

sudo loginctl enable-linger "$USER"
export ORCA_TERMINAL_MEMORY_MAX=3G
export ORCA_TERMINAL_MEMORY_SWAP_MAX=1G
orca-ide serve --port 6768 --pairing-address 100.64.1.20

Orca reads ORCA_TERMINAL_MEMORY_MAX when its terminal host (orcad) first starts. Never pass 0.0.0.0 or 127.0.0.1 to --pairing-address: Orca rejects wildcards, and remote clients cannot reach 127.0.0.1. Because --pairing-address only sets the IP inside the orca://pair?code=... link rather than restricting the socket bind, block public ingress to TCP port 6768 in your cloud firewall and ufw. Allow traffic only over tailscale0.

Remote clients disable the UI Add account button. Register your coding agents on the VM using device auth so the browser login finishes on your laptop (Remote Orca Servers, accessed 2026-11-02):

orca-ide account add --agent claude
orca-ide account add --agent codex

3. Why .worktreeinclude and .env Files Collide on Remote VMs

Orca gives every task its own git worktree and branch so parallel agents do not overwrite each other’s files (Worktrees, accessed 2026-11-02). Because git worktree add skips gitignored files, Orca offers two helpers:

1. worktree.sharedDirectories in orca.yaml: Symlinks up to 100 gitignored directories (such as node_modules) from the primary checkout into each new worktree.
2. .worktreeinclude at the repo root: Copies gitignored literal file paths (up to 1,000 path lines, capped at 2 GiB and 50,000 filesystem entries per worktree; Orca skips * and ? globs) into each new worktree (orca.yaml reference, accessed 2026-11-02).

In What Is an ADE?, we showed the basic local pattern where .worktreeinclude copies .env into each worktree. On a remote VM running autonomous agents, that pattern becomes a security problem:

• Agents run with permission prompts bypassed: As noted in Orca’s docs (docs/site/content/docs/agents/supported.mdx) and GitHub Discussion #29584 (published October 16, 2026), Orca starts coding agents with permission-bypass flags by default (--dangerously-skip-permissions, --dangerously-bypass-approvals-and-sandbox, or --yolo). Git worktrees are isolated checkouts, not security sandboxes.
• Plaintext .env sprawl: Putting .env in .worktreeinclude (or copying $ORCA_ROOT_PATH/.env in scripts.setup) writes plaintext database URLs and API keys into every worktree directory [INFERENCE].

4. Wiring Infisical into Your Remote Orca Workspace

Instead of storing .env files on disk, authenticate the VM to Infisical with a Machine Identity scoped to dev (never prod; for production leases and rotation, see Build for the Leak). Then separate how you pass secrets by workload:

• One-shot test runs and builds need real variables in memory (DATABASE_URL, REDIS_URL). Run them with infisical sm run in a separate Orca tab after reviewing the agent’s diff.
• Coding agents (claude, codex) should never hold raw third-party keys in their environment or filesystem. Run them inside infisical sm agent-proxy run, which sandboxes the agent with bubblewrap (bwrap) and attaches HTTP(S) credentials in flight.

flowchart TB
  subgraph VM["Free-Tier Linux VM (Ubuntu 24.04 + Orca Worktree)"]
    MI["Machine Identity Auth<br/>(Universal Auth / AWS IAM / GCP ID Token)"]
    
    subgraph Tab2["Orca Tab 2: Tests (Outside bwrap)"]
      SM["infisical sm run"] --> DEV["pnpm test<br/>(In-memory dev vars; no .env on disk)"]
    end

    subgraph Tab1["Orca Tab 1: Coding Agent"]
      PROXY["Infisical Local Agent Proxy<br/>(In-memory Root CA + proxy.sock)"]
      subgraph BWRAP["bubblewrap Sandbox (Empty Network Namespace)"]
        AGENT["claude / codex<br/>Placeholders only; ~/.ssh & ~/.infisical hidden"]
      end
      AGENT -- "HTTP_PROXY (127.0.0.1:17321 -> proxy.sock)" --> PROXY
    end

    MI --> SM
    MI --> PROXY
  end

  INF["Infisical API (dev scope)"] -- "Fetches /app secrets" --> SM
  INF -- "Fetches /coding-agent secrets" --> PROXY
  PROXY -- "Attaches real header" --> UP["GitHub / Upstream HTTP(S) APIs"]

Step 1: Install Infisical CLI (>= 0.44.8) and Authenticate the VM

Install the Infisical CLI on the VM and check its version. Infisical added the infisical sm namespace and .infisical.yaml in CLI 0.43.145. It requires 0.44.8 or newer for environment, secret-path, and overrides.git-branch in .infisical.yaml (Infisical CLI reference and project configuration, accessed 2026-11-02).

On a headless VM, skip interactive user logins (infisical login), which fall back to an encrypted file vault at ~/infisical-keyring with a passphrase in ~/.infisical/infisical-config.json. Use a Machine Identity instead (Infisical CLI login reference, accessed 2026-11-02).

On Oracle Cloud, use Universal Auth with the CLI: as of November 2026, Infisical’s OCI Auth is an API/SDK method rather than a built-in infisical login --method flag. Store the Universal Auth client secret at ~/.infisical/client-secret with 0700/0600 permissions. That path matters: infisical sm agent-proxy run hides ~/.infisical inside bubblewrap, whereas ~/.config/infisical/ stays readable inside the sandbox [INFERENCE].

Because infisical sm agent-proxy run does not refresh INFISICAL_TOKEN mid-session, mint a fresh token inline when starting commands so long-lived Orca sessions never use an expired token:

infisical --version  # Verify >= 0.44.8
install -d -m 0700 ~/.infisical && chmod 0600 ~/.infisical/client-secret

# Option 1: Oracle Cloud (OCI) or any Linux VM via Universal Auth
export INFISICAL_UNIVERSAL_AUTH_CLIENT_ID="<client-id>"
INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET="$(cat ~/.infisical/client-secret)" \
  infisical login --method=universal-auth --silent --plain

# Option 2: AWS EC2 VM with an attached IAM Role (no static secret on disk)
infisical login --method=aws-iam --machine-identity-id="<identity-id>" --silent --plain

# Option 3: Google Cloud e2-micro with an attached Service Account
infisical login --method=gcp-id-token --machine-identity-id="<identity-id>" --silent --plain

Step 2: Commit .infisical.yaml and orca.yaml

.infisical.yaml holds only your project ID and path mapping. Commit it to Git so every worktree gets it without .worktreeinclude:

# .infisical.yaml (requires Infisical CLI >= 0.44.8)
version: 1
secrets-management:
  project-id: "00000000-0000-0000-0000-000000000000"
  environment: "dev"
  secret-path: "/coding-agent"

Watch out for one CLI rule: when authenticated as a Machine Identity, infisical sm run, sm export, and sm secrets ignore project-id in .infisical.yaml and require --projectId or INFISICAL_PROJECT_ID (Infisical project configuration, accessed 2026-11-02). By contrast, infisical sm agent-proxy run and connect do read project-id from .infisical.yaml. Exporting INFISICAL_PROJECT_ID in your shell profile satisfies both.

Next, add orca.yaml at the repo root. Follow two rules from the orca.yaml reference for defaultTabs:

1. Reserve the first tab for the agent: In Orca’s desktop create composer, picking an agent overwrites the first template tab’s command. Put test or helper tabs second.
2. Use hex colors and avoid file-watching sm run loops: color requires #RGB or #RRGGBB (Orca ignores named colors like "blue"). Also, do not run a file-watching dev server (pnpm dev) under infisical sm run outside bwrap while an agent edits the same worktree. Any code the agent writes would execute immediately inside the unsandboxed sm run process [INFERENCE]. Run tests on demand after reviewing the diff, and scope /app to disposable dev credentials:

# orca.yaml
setupAgentStartupPolicy: wait-for-setup

worktree:
  sharedDirectories:
    - node_modules
    - .next/cache

scripts:
  setup: |
    set -euo pipefail
    if [ -d "$ORCA_ROOT_PATH/node_modules" ] && [ ! -e "$ORCA_WORKTREE_PATH/node_modules" ]; then
      ln -s "$ORCA_ROOT_PATH/node_modules" "$ORCA_WORKTREE_PATH/node_modules"
    fi

defaultTabs:
  - title: "agent"
    color: "#10b981"
  - title: "test-runner"
    command: "echo 'Run after diff review: infisical sm run --projectId=$INFISICAL_PROJECT_ID --env=dev --path=/app -- pnpm test'"
    color: "#3b82f6"

Remove .env and .env.local from .worktreeinclude. Keep only non-secret files such as .vscode/settings.json there.

Step 3: Launch Coding Agents Inside the Linux bubblewrap Sandbox

In the worktree’s agent tab, mint a fresh token and start the agent inside infisical sm agent-proxy run (Infisical local Agent Proxy, accessed 2026-11-02):

INFISICAL_TOKEN="$(INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET="$(cat ~/.infisical/client-secret)" \
  infisical login --method=universal-auth --silent --plain)" \
  infisical sm agent-proxy run --env=dev --path=/coding-agent -- claude

On Linux, infisical sm agent-proxy run locks down the agent in five ways:

1. Empty network namespace via bubblewrap (bwrap): bwrap creates an isolated network namespace with no external interface and blocks DNS. Any tool that ignores HTTP_PROXY/HTTPS_PROXY fails immediately (Could not resolve host) instead of bypassing the proxy.
2. Loopback TCP bridge to proxy.sock: Inside the sandbox, a supervisor listens on 127.0.0.1:17321 (HTTP_PROXY/HTTPS_PROXY) and forwards traffic to the host proxy over a Unix socket (proxy.sock) in a 0700 temp directory (/tmp/infisical-agent-proxy-run-XXXXXX/).
3. Ephemeral in-memory Root CA: On macOS, Infisical writes the CA to ~/.infisical/agent-proxy and prompts for the login keychain. On Linux, it generates a fresh root CA in memory for each run and never writes the private key to disk. It writes only local-ca.pem and points SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, GIT_SSL_CAINFO, and DENO_CERT at it.
4. Environment scrubbing: The proxy strips variables matching *TOKEN*, *SECRET*, *PASSWORD*, *API_KEY*, *PRIVATE_KEY*, or *ACCESS_KEY*, plus SSH_AUTH_SOCK and INFISICAL_*. Device-auth accounts added via orca-ide account add --agent claude or codex keep working because their auth state lives in ~/.claude and ~/.codex rather than environment variables [INFERENCE]. Pass --pass-env=ANTHROPIC_API_KEY only if you authenticate with raw API key env vars.
5. Credential path masking: bwrap masks existing host paths—including ~/.infisical, ~/infisical-keyring, ~/.aws, ~/.ssh, ~/.gnupg, ~/.kube, ~/.netrc, ~/.npmrc, ~/.git-credentials, and ~/.config/gh—with empty tmpfs mounts or /dev/null. Only the active Orca worktree, ~/.claude, ~/.claude.json, and ~/.codex stay read-write.

Optional Upgrade: Two-VM Separation on Oracle Always Free

In single-VM mode, the host proxy process lives on the same machine as the sandboxed agent. For host-level isolation at $0, combine both Oracle Always Free shapes on one private VCN [INFERENCE]:

• VM 1 (VM.Standard.E2.1.Micro, 1 GB RAM, private subnet): Runs infisical sm agent-proxy start on port 17322 (restricted by VCN security rules to the private subnet) using a Proxy Machine Identity (Read Value, Describe Secret, Report Usage) (Infisical standalone Agent Proxy, accessed 2026-11-02). It renews its Universal Auth token automatically and polls secrets every 60 seconds.
• VM 2 (VM.Standard.A1.Flex, 12 GB RAM, workspace host): Runs orca-ide serve and connects agents via infisical sm agent-proxy connect --proxy=<micro-private-ip>:17322 --env=dev --path=/coding-agent -- claude. Its Agent Machine Identity holds only the Proxy permission and cannot read secret values from Infisical.

5. Common Linux VM Pitfalls and Fixes

• Ubuntu 24.04 AppArmor blocks bwrap user namespaces: Ubuntu 24.04 sets kernel.apparmor_restrict_unprivileged_userns=1. If bwrap cannot create a user namespace, infisical sm agent-proxy run refuses to start and prints fix instructions (Infisical local Agent Proxy, accessed 2026-11-02). Confirm /etc/apparmor.d/bwrap is loaded (sudo apparmor_parser -r /etc/apparmor.d/bwrap) or check sysctl kernel.apparmor_restrict_unprivileged_userns.
• Dev servers inside agent-proxy run are unreachable: Because bwrap isolates the network namespace, a server started inside agent-proxy run is invisible to the host and Orca port forwarding, and the agent cannot reach 127.0.0.1:5432 on the VM. Run dev servers and database tests in a separate Orca tab outside bwrap.
• Non-HTTP traffic fails through the proxy: Agent Proxy only brokers HTTP and HTTPS (HTTP/1.1). SSH git pushes (git@github.com:...), raw Postgres TCP connections, and WebSockets fail inside agent-proxy run (Infisical local Agent Proxy, accessed 2026-11-02). Use https://github.com/... remotes with a proxied GitHub token, or push over SSH from a normal Orca tab.

6. Verification Checklist

Run these three checks in an Orca worktree terminal before starting agent work:

1. Confirm node_modules is symlinked (lrwxrwxrwx), not copied:

ls -ld "$PWD/node_modules"

2. Confirm no .env file exists in the worktree (expect empty output):

find "$PWD" -maxdepth 2 -name ".env*"

3. Confirm bwrap scrubs INFISICAL_TOKEN and masks ~/.infisical/client-secret:

infisical sm agent-proxy run --env=dev --path=/coding-agent -- \
  sh -c 'echo "token=${INFISICAL_TOKEN:-scrubbed}"; ls -la ~/.ssh ~/.infisical; cat ~/.infisical/client-secret 2>&1 || true'

If that command prints token=scrubbed and fails to read ~/.infisical/client-secret, your workspace is ready. Every new Orca worktree now shares node_modules without eating disk space, runs inside per-terminal memory limits, and keeps raw .env credentials off the filesystem and out of the agent’s process environment [INFERENCE].

Sources

We consulted all sources below on November 2, 2026:

• Orca (stablyai/orca):
  • Ways to run Orca and SSH worktrees — SSH Target vs. Remote Orca Server, ~/.orca-remote/ (orcad), and build-essential python3 requirements for node-pty.
  • Remote Orca Servers, Issue #28320 / PR #28871, and Headless Linux Server reference — orca-ide serve --pairing-address, Tailscale pairing, orca-ide account add --agent, loginctl enable-linger, and ORCA_TERMINAL_MEMORY_MAX systemd scopes.
  • Install Orca and Orca CLI reference — Linux orca-ide binary naming (/usr/bin/orca GNOME screen reader collision).
  • Worktrees and orca.yaml & .worktreeinclude reference (PR #9791, PR #10459) — worktree.sharedDirectories, .worktreeinclude limits, defaultTabs rules, and why SSH Target mode uses scripts.setup.
  • GitHub Discussion #29584: Container worktrees (published 2026-10-16) — Orca’s default permission-bypass flags (docs/site/content/docs/agents/supported.mdx) and worktree isolation boundaries.
• Infisical:
  • Infisical Local Agent Proxy — infisical sm agent-proxy run, Linux bubblewrap (bwrap) sandbox, loopback bridge to proxy.sock, in-memory Root CA, environment scrubbing, and Ubuntu 24.04 AppArmor behavior.
  • Infisical Standalone Agent Proxy and Proxied Services — infisical sm agent-proxy start (port 17322), connect, 60-second polling, and Proxy vs. Agent Machine Identity roles.
  • Infisical CLI reference, CLI Login section, Project configuration (.infisical.yaml), and OCI Auth — CLI 0.43.145 and 0.44.8 cutoffs, version: 1, --method=universal-auth / aws-iam / gcp-id-token, and --projectId requirements on sm run.
• Cloud Free Tiers (mutable quotas checked 2026-11-02):
  • Oracle Cloud Always Free Resources — June 15, 2026 VM.Standard.A1.Flex cap (1,500 OCPU-hours and 9,000 GB-hours/month, or 2 OCPUs / 12 GB RAM continuous), VM.Standard.E2.1.Micro, 200 GB Block Volume, and 7-day idle reclamation rules.
  • AWS Free Tier — July 15, 2025 credit program (up to $200 USD in credits; 6-month Free Plan vs. 12-month Paid Plan).
  • Google Cloud Free Program — Always Free e2-micro (1 GB RAM in us-west1, us-central1, or us-east1, 30 GB Standard Persistent Disk).
  • GitHub Codespaces — 120 core-hours/month and 15 GB storage on personal accounts.