[Back to blog](https://zcp.zsoftly.ca/blog) [Engineering](https://zcp.zsoftly.ca/blog/category/engineering) # Why I Love Orca for ZSoftly’s Development Workstations How ZSoftly is designing dedicated developer workstations on ZCP, with Orca across interactive work and a separate CI/CD path for execution. Ditah Kumbong November 4, 2026 4 min read Share ![ZCP engineering cover about shared development workstations on ZCP](https://zcp.zsoftly.ca/images/blog/2026/shared-development-workstation-orca-zcp.webp) I love Orca. It gives me one place to work with Claude Code, Codex, terminals, and Git worktrees. At ZSoftly, I am using that idea to define a practical development-workstation standard for business application work. The goal is a dedicated workspace for each developer, with persistent projects, familiar tools, and a clear separation between interactive work and CI/CD execution. ZSoftly Cloud Platform (ZCP) hosts the infrastructure, and ZSoftly Professional Services designs and manages the environment around it. ## The workspaces I need every day My work spans three workspace groups. ### ZSoftly - Folder: `~/zsoftly` - Repositories: `core`, `web`, `infra`, `cli`, `business` - Lead workspace: `company-claude-lead` or `company-codex-lead` ### Client A - Folder: `~/client-a` - Repositories: `core`, `web`, `infra`, `cli`, `business` - Lead workspace: `client-a-claude-lead` or `client-a-codex-lead` ### Client B - Folder: `~/client-b` - Purpose: ZSoftly-managed client project One reusable workstation pattern keeps related repositories, worktrees, terminals, and review context together without rebuilding the environment on every laptop. ## A dedicated VM per developer The target standard is a dedicated Ubuntu 26.04 LTS virtual machine per developer. It includes Claude Code and Codex, Git worktrees, Terraform and Ansible, Docker and Kubernetes tools, SSH and Herdr, plus KDE when a graphical desktop is useful. Ubuntu 26.04 LTS is the target standard for this pattern, not a claim about the operating system on any client VM. Reference workstation layout. Disk sizes are target allocations, not a claim about every live workstation or verified backup schedule. Developer laptop Browser and private access entry point Dedicated Ubuntu 26.04 LTS VM Claude Code, Codex, terminals, Git worktrees, and developer tools OS disk: 40 to 60 GB OS, tools, configuration, and system logs. OS backup is part of the design. Data disk: 250 GB Repositories, worktrees, Docker layers, caches, and build output. Projects need their own recovery policy. GitHub → Reviewed PR → CI/CD → Managed CI runners The OS disk is a reference 40 to 60 GB allocation for the operating system, developer tools, configuration, and system logs. The design includes OS backup. A separate 250 GB data disk holds project repositories, worktrees, separate Docker layers, Go and npm caches, and build output. Persistent projects and uncommitted worktrees need different treatment from disposable caches. OS backups and automated rebuilding address the operating environment. Workspace recovery is separate. GitHub stores committed source, while work in progress needs its own recovery policy. The data disk should not be treated as one disposable or automatically backed-up bucket. ## Orca across the workspaces I use Orca to organize Claude Code, Codex, terminals, and Git worktrees across the ZSoftly developer workstation pattern. The default remains a dedicated VM per developer. For trusted client work such as Client B, Orca also provides a shared remote runtime for projects, worktrees, terminals, provider accounts, and agent sessions. That shared model is useful for client work such as Client B, where pairing grants are private and revocable but do not create isolated user accounts. Worktrees separate tasks, not users. The Orca remote-server feature is beta, so I am treating it as a controlled team foundation rather than a finished platform offering. The current Client B access setup provides browser access through a restricted HTTPS path and private pairing. Its browser user interface, pairing, and reconnect after the pairing helper stopped were verified. Provider accounts, a first coding workflow, and backup or recovery behavior remain to be configured and tested. The first three screenshots show the client’s initial setup views. The gallery also includes my Orca Mobile overview, agent dashboard, and project terminal. The browser asks for a private pairing code. No automations are configured in this view. The workspace is shown before repositories are added. Orca Mobile overview with paired devices and a phone preview. The agent dashboard groups sessions by status. A project terminal beside company and client workspaces. ## CI/CD stays separate from the interactive workstation The interactive VM is where a developer plans, edits, reviews, and tests scoped work. GitHub remains the system of record for committed source. The delivery path stays explicit: GitHub to reviewed pull request to CI/CD. Managed CI runners handle testing and execution. I am not turning the Orca VM into a CI runner. This split keeps a developer’s working environment useful without mixing interactive sessions with automated execution. It also gives the team a clear place to review changes before they move into the delivery path. ## The pattern I am building I want developers to have their own durable workstation, while trusted client teams use a shared Orca runtime when shared context is the right fit. ZCP supplies the virtual infrastructure. ZSoftly Professional Services supplies the design, deployment, onboarding, and operating controls. If your team needs a private development environment or application delivery foundation, use the contact details below to start a scoping conversation. ## Related articles Engineering November 4, 2026 ### [How Zenphry Built a Reusable Office Connection for Its Remote Team](https://zcp.zsoftly.ca/blog/remote-teams-office-network) How Zenphry built an approved remote-access foundation with a Headscale VPN control plane on ZCP, a Dallas exit node, Tailscale clients, and managed routers. Engineering October 11, 2026 ### [The Restart That Hid a Libvirt Bug](https://zcp.zsoftly.ca/blog/the-restart-that-hid-a-libvirt-bug) A seven-minute VM create, two wrong turns, a self-healing timer I built and then deleted, and the package update that fixed it. Engineering October 5, 2026 ### [Private Desktops: Lessons from Testing](https://zcp.zsoftly.ca/blog/what-we-learned-testing-private-employee-desktops) What to test before a private desktop rollout: daily work, video calls, network paths, storage, and offboarding.