10 Remote Development Best Practices

Sergei Petunin

The concept of remote development is deceptively simple: spin up your development environment somewhere that’s not your local machine. The perks range from freeing up local resources to not panicking when your laptop gets stolen.

Yet, there are plenty of pitfalls, including flaky setups, poor visibility, and lousy monitoring. Let’s look at some best practices of remote development and see what JetBrains has to offer.

1. Get rid of RDP/VNC/VDS

If you’re still “remote developing” by pixel-streaming, you’re wasting your time. Real remote development feels local, handles flaky networks gracefully, and scales far beyond your laptop.

Reality check: Streaming your whole desktop is like lugging a cinema projector over SSH. Every keystroke triggers massive pixel redraws, your IDE becomes sluggish, and one lost packet freezes everything. Why move video frames instead of code diffs? Modern remote protocols only send keystrokes and UI deltas. Latency plunges, and your IDE snaps back to life.

2. Stay online, even when you’re not

Flaky Wi-Fi isn’t an excuse anymore. A proper remote development client buffers your edits locally, shows a “reconnecting” notice, and pushes your changes when you’re back online. Linting, inspections, breakpoints – they pick up seamlessly. You keep context, and your work never vanishes into thin air.

3. Enterprise-grade orchestration

One VM or container remotely? Sure, great for demos. But ten teams? A dozen projects? Manual SSH scripts crumble fast. You need a Cloud Dev Environment (CDE) orchestrator that addresses the following pain points:

If you’re not automating this stuff, you’re putting your team at a disadvantage.

4. CodeCanvas: JetBrains’ answer

We built CodeCanvas to cover every base:

• Dev environment templates: Versioned, shareable, based on Docker images (build your own if needed), IDE backends included.
• Auto-provisioning: Plugins, VS Code extensions, secrets – everything installs itself.
• Cost control: Idle workspaces auto-stop, warm-up snapshots and standby pools minimize startup delays.
• Zero-trust security: WebSocket relays (no inbound pods), SSH jump servers as needed, and strict clipboard restrictions.
• Observability: Real-time dashboards to monitor environment creation, adoption rates, crashes, and idle times.

5. Borrow, don’t reinvent – follow the leaders

• GitHub Codespaces: Uses devcontainer.json, spins up on GitHub’s infrastructure.
• Gitpod: Declares workspace configuration via .gitpod.yml, provides consistent branch environments.
• AWS Cloud9: Automates EC2 provisioning and Docker setup via AWS APIs, browser-based and fully scriptable.
• CodeCanvas: Scalable Kubernetes-based environments (EKS, AKS, GKE, or your bare-metal clusters) designed for distributed teams.

If you’re building your own, ask yourself: what do these platforms handle that I’m missing?

6. Workflow orchestration beats task automation

Creating a VM is just a task. Combining container builds, secret management, post-hooks, health checks, and cleanup – that’s orchestration. True CDE platforms handle this complexity gracefully. If you’re still scripting “docker run” in shell scripts, you’re reinventing the wheel.

7. Short-lived environments are mandatory

If you try to cram everything into a single long-living environment, you’ll just be stuck twiddling your thumbs during branch switches and rebuilds. When environments spin up in seconds, they become disposable. This allows a fresh environment for each feature or code review, tossed away as soon as you’re done with it. Warm-up snapshots and standby pools have turned “cold start” into a thing of the past. Short-lived CDEs ensure consistency, security, and predictable costs.

8. Security and compliance: don’t get pwned

• Zero trust: Authenticate and authorize every single IDE connection.
• Network isolation: Use per-cluster relays and jump servers with no direct SSH. Restrict clipboard actions to prevent data leaks.
• Policy enforcement: Align your practices with security benchmarks – development environments are vulnerable if left unguarded.

9. Metrics that actually matter

Dashboards aren’t just window dressing – they drive optimization. Get an overview of:

• Startup latency: From spin-up to first build or indexing.
• Resource utilization: CPU, memory, and I/O per workspace.
• Idle time: Triggers for auto-shutdown.
• Failure rates: Backend crashes, reconnections.

Use tools like Prometheus/Grafana, Dynatrace, or cloud-native monitoring to correlate developer efficiency with infrastructure health.

10. AI agent support – no longer optional

Your CDE orchestration now has to treat AI agents like first-class citizens, not just humans. That means clean APIs, bulletproof permissions, and tight resource controls. Mistakes here mean you’ll find yourself quickly outdated in a landscape where AI isn’t optional anymore.

Bottom line

If you’re clinging to RDP, VDI, manual SSH hacks, or one-off VMs, you’re consciously choosing friction over productivity. Embrace protocol-smart remote dev clients, short-lived environment orchestration, zero-trust security, and meaningful metrics. Whether you adopt CodeCanvas, Codespaces, Gitpod, or AWS Cloud9 – these patterns aren’t optional if you care about scale, security, and developer velocity.

Subscribe to CodeCanvas Blog Updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!