Why We Started Building Another Remote Development Environment
Remote development has become the default way many teams work.
Whether you're using VS Code Remote SSH, GitHub Codespaces, Coder, DevPod, or a self-hosted Kubernetes workspace, the promise is the same:
Your development environment lives in the cloud while your editor stays local.
The advantages are obvious.
But over the last year, another problem emerged.
AI became part of the development workflow.
Developers aren't just editing code anymore.
They're asking AI to:
And that's where many remote development platforms start showing cracks.
The development environment itself is no longer the expensive part.
AI is.
After repeatedly hitting AI usage limits while working on production systems, I started wondering:
Why is my editor unlimited, my compute unlimited, but my coding assistant constantly rate-limited?
That question eventually led us to build Neural Inverse Cloud.
Not because the world needed another IDE.
Because we wanted to explore whether a remote development platform could include AI as infrastructure instead of treating it as a premium add-on.
This article walks through the architecture behind that decision and how we built a VS Code Remote alternative capable of supporting unlimited AI assistance.
At a high level, the system consists of four layers:
Developer Browser
│
▼
Global Traffic Router
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
US Region Europe Region Asia Region
│ │ │
▼ ▼ ▼
Kubernetes Pods Kubernetes Pods Kubernetes Pods
│ │ │
└───────────────┬────┴─────┬──────────────┘
│ │
▼ ▼
Gitea AI Gateway
│ │
▼ ▼
Persistent Azure AI
Storage Foundry
The goal was simple:
Provide a development environment that behaves like VS Code Remote while integrating AI directly into the platform.
Each workspace runs inside Kubernetes.
Current configurations include:
| Tier | CPU | RAM |
|---|---|---|
| Starter | 2 vCPU | 2 GB |
| Standard | 4 vCPU | 8 GB |
| Pro | 8 vCPU | 32 GB |
Initially we assumed scaling challenges would come from compute.
We were wrong.
The real challenge was maintaining consistent performance.
Large builds running beside smaller workloads created noisy-neighbor issues.
Developers noticed immediately.
The solution was dedicated node pools.
apiVersion: apps/v1
spec:
template:
spec:
nodeSelector:
workspace-tier: dedicated
tolerations:
- key: workspace-tier
operator: Equal
value: dedicated
This ensured predictable CPU allocation and removed most performance spikes.
One thing VS Code Remote does extremely well is feeling instant.
Cloud workspaces often don't.
Our first implementation created workspaces on demand.
That meant:
The result was several minutes of waiting.
Not acceptable.
Instead, we switched to pre-warmed workspace pools.
def create_workspace(user):
pod = get_prewarmed_pod()
attach_storage(user.volume)
assign_owner(user.id)
return pod.endpoint
Most workspace launches now complete in under a minute.
The difference in perceived performance is enormous.
Containers fail.
Nodes fail.
Regions fail.
Developer work should survive all three.
We solved this by separating execution from persistence.
Instead of treating containers as the source of truth, every workspace continuously synchronizes with Git.
git add .
git commit -m "Workspace checkpoint"
git push origin main
Internally we use Gitea.
Git becomes the recovery mechanism.
Not the container.
This allows:
Workspaces become disposable infrastructure.
Developer data does not.
Most cloud IDE articles stop at infrastructure.
We couldn't.
Because AI had become the most expensive part of the stack.
A typical remote workspace consumes predictable compute resources.
AI usage doesn't.
One developer might generate 5,000 tokens.
Another might generate 5 million.
Traditional pricing handles this by introducing limits.
We wanted to see if we could avoid them entirely.
The answer isn't technical.
It's economic.
Most AI tools charge directly for inference.
More prompts means more cost.
Eventually limits become necessary.
Instead, we tied pricing to compute allocation.
Developers pay for workspace resources.
AI becomes part of the environment.
This changes the economics significantly.
Instead of asking:
"How many tokens did this user generate?"
We ask:
"Can AI costs remain a small percentage of workspace revenue?"
The answer turns out to be yes.
Typical 4-vCPU workspace:
| Component | Cost/hr |
|---|---|
| AI Inference | $0.10 |
| Storage | $0.02 |
| Network | $0.02 |
| Total Cost | $0.14 |
Revenue:
| Component | Revenue/hr |
|---|---|
| Compute | $0.96 |
Even heavy AI usage remains sustainable.
More importantly:
AI costs continue falling every quarter.
The economics improve over time rather than deteriorate.
Running our own GPU fleet never made sense.
Managing GPUs introduces:
Instead we route requests through Azure AI Foundry.
Current model stack:
Requests are dynamically routed.
def choose_model(task):
if task == "reasoning":
return "deepseek-r1"
if task == "coding":
return "llama-4"
return "mistral-large"
Adding new models becomes configuration rather than infrastructure.
The platform currently operates across:
Workspaces stay region-local.
We intentionally avoided live migration.
While technically possible, it introduces complexity around storage consistency and recovery.
Benefits:
Trade-offs:
For most developers, this is the right compromise.
One reason we open-sourced the project was enabling self-hosting.
Some teams simply can't use a multi-tenant cloud.
Examples include:
Deployment is straightforward.
Clone the repository:
git clone https://github.com/neuralinverse/neuralinverse
cd neuralinverse
Configure environment variables:
cp .env.example .env
Launch the stack:
docker compose up -d
Verify services:
docker ps
After deployment, workspaces can be created through the web dashboard.
A typical workflow looks like this:
Create a workspace.
Platform assigns a pre-warmed Kubernetes pod.
Open the browser IDE.
Workspace is immediately available.
Start coding.
Use AI for:
Changes automatically synchronize through Git.
Workspace can be stopped, restarted, or migrated without losing work.
The developer experience feels similar to VS Code Remote but with cloud-native infrastructure underneath.
Building a remote development platform taught us several lessons.
First, infrastructure isn't the hard part anymore.
Kubernetes, storage, networking, and orchestration are well-understood problems.
The interesting challenge is integrating AI sustainably.
Second, economics matter as much as architecture.
Many engineering discussions focus on technology.
In reality, pricing models often determine whether a platform succeeds.
Finally, open source builds trust.
Engineers want to inspect the implementation.
They want to verify assumptions.
They want to understand trade-offs.
Making the platform open source allowed those conversations to happen.
The goal wasn't to replace VS Code.
The goal was to explore what remote development looks like when AI becomes a first-class part of the infrastructure.
The resulting platform combines:
None of these ideas are individually new.
What's interesting is how they work together.
If you're interested in exploring the implementation:
GitHub: https://github.com/neuralinverse/neuralinverse
Try it online: https://cloud.neuralinverse.com
I'd love to hear how others are approaching remote development, AI integration, and cloud-native IDE architectures.