
Ask developers where they spend the working day. The [2025 Stack Overflow survey](https://survey.stackoverflow.co/2025/technology) answers with a list, and the list has a property nobody remarks on:

| Development environment | Share of developers |
|-------------------------|---------------------|
| VS Code | 75.9% |
| Visual Studio | 29% |
| Notepad++ | 27.4% |
| IntelliJ IDEA | 27.1% |
| Vim | 24.3% |

<p class="table-source">Stack Overflow Developer Survey 2025, development environments, multi-select, so shares exceed 100% combined.</p>

Every entry is a desktop app. The decade that moved email, docs, design, and project management into the browser left the tools developers live in untouched, and the company that owns the world's largest web platform ships its flagship editor as a local program.

We're building ICE, our Integrated Cloud Environment, as a desktop app, and in 2026 that reads as contrarian. My claim is that it's the opposite: for instruments, the tools a professional plays for hours a day, desktop never lost, and infrastructure tooling is an instrument that got misfiled as a website.

## Documents versus instruments

The browser's wins share a shape: the thing being worked on is a shared artifact, and the URL is the artifact. Docs, tickets, wikis. Distribution beats latency for those, because the collaboration is the product.

Instruments have the opposite shape. An editor, a terminal, a debugger: you inhabit them, they own your keyboard, and they touch local resources constantly. A browser tab can't fully own the keyboard; Cmd-W is always one reflex away from closing your session, and the tab boundary keeps your tool at arm's length from the filesystem, the OS keychain, and your running processes. Latency compounds too. A person who triggers an interaction thousands of times a day feels every added millisecond as friction, which is a large part of why 75.9% of the industry works in a local editor while writing software for the cloud.

There's a quieter dependency too: instruments get customized. Keybindings, themes, dotfiles carried between jobs like family recipes. A tool you shape to your hands is a tool you keep, and the browser makes that shaping shallow, because in a tab the state belongs to the site rather than to you.

## An operating session is a place, not a page

Cloud consoles are forms. Stateless, per-request, amnesiac: every visit starts from a dashboard that has forgotten your context, and the context is the job. Working on infrastructure means holding a model across an afternoon, and the tab-shaped version of that model evaporates on every reload. Anyone who has rebuilt a seven-tab investigation after one accidental window close knows the tax.

There's a darker version of this argument, and October 2025 supplied it. During [Azure's October 29 outage](https://www.thousandeyes.com/blog/microsoft-azure-front-door-outage-analysis-october-29-2025), the Azure portal itself was impaired, meaning the tool for managing the blast radius was inside the blast radius. The local-first movement wrote the principle down years before that outage made it vivid:

<figure class="research-quote">
  <blockquote>...the availability of another computer should never prevent you from working.</blockquote>
  <figcaption>Kleppmann, Wiggins, van Hardenberg, and McGranaghan, "Local-first software", Ink &amp; Switch, 2019. <a href="https://www.inkandswitch.com/essay/local-first/">Essay</a></figcaption>
</figure>

Your model of your infrastructure, the map you need most during an outage, shouldn't be hosted inside the thing that's on fire. ICE's graph lives on your machine. The clouds can be down and the map still opens.

Credentials follow the same logic. A browser-based tool that talks to AWS, GCP, and Azure on your behalf generally means your cloud credentials transit somebody's backend, and that somebody becomes part of your attack surface. The design goal of a desktop app is blunter: keys stay in the OS keychain, API calls go from your machine to your clouds, and we never hold what we can't lose.

## Figma is the counterargument

The steelman has a name. Figma beat entrenched native design tools from inside a browser tab, and the reasons were real: nothing to install, a URL is the file, multiplayer by default. Distribution through a link is a genuinely superior adoption model, and no update ever ships late to a browser. I'll concede the blurry boundary too. Plenty of "desktop apps" are Electron, a bundled browser in a native coat, so the war looks over if you squint. And building desktop means carrying the update, signing, and packaging tax that the web abolished; we pay that tax and it's not small.

But look at what Figma's users collaborate on: the canvas itself, an artifact safe to share by URL. Infrastructure's object is a live system wearing credentials, where "anyone with the link" is the beginning of an incident report, and where the collaboration layer already exists and is called git. And Electron's popularity argues my side, quietly: when teams could ship a tab, they still chose a desktop shell to get the keyboard, the tray, the keychain, and the filesystem. The UI technology surrendered. The deployment target didn't.

Defending this choice publicly is the point of making it. ICE is in development, the desktop decision is made, and if it's wrong we'll find out in the most instructive way available. My bet: the people who spend all day operating infrastructure will want what people who spend all day writing code already have, a local instrument with the full model inside it.

Here's a test you can run on yourself. The last time you were paged, how long did you spend finding the right console tab and re-authenticating before you could even look at the problem? Now compare that with how long your editor takes to open from the dock. Muscle memory already voted.

---

Related: [Integrated Cloud Environment](/dev-tools/integrated-cloud-environment), where we introduced what ICE is.
More about what we're building at [light-cloud.com](https://light-cloud.com).


The browser won documents. It never won instruments.

Why We're Building a Desktop App in 2026


Around three cents. That's the ballpark lifetime cost of the thing that most changed how code review feels on Light Cloud: a full, disposable copy of the application, on its own URL, for every branch. Not a screenshot bot, and not a staging server you book in a spreadsheet. A real environment, created on push, destroyed on merge.

Here's the claim: preview environments stopped being a luxury the moment scale-to-zero billing became real, and the remaining cost isn't infrastructure. It's engineering discipline, and most of that discipline is teardown. This post shows the arithmetic and the machinery, including the parts that bite, because "cheap previews" sounds like marketing until you can check the meter yourself.

## Where "around three cents" comes from

A preview on our platform is a container that scales to zero. It bills nothing while idle, and idle is most of its life. The representative preview below assumes fifteen minutes of cumulative active traffic across its entire existence, one vCPU, 512 MiB of memory, and public [Cloud Run list prices](https://cloud.google.com/run/pricing) in a standard region as of August 2026.

| Line item | List rate | This preview uses | Cost |
|-----------|-----------|-------------------|------|
| CPU | $0.000024 / vCPU-second | 900 vCPU-seconds | $0.0216 |
| Memory | $0.0000025 / GiB-second | 450 GiB-seconds | $0.0011 |
| Requests | $0.40 / million | ~10,000 requests | $0.0040 |
| Total | | | ~$0.027 |

<p class="table-source">List rates from the public Cloud Run pricing page, standard region, request-based billing, as of August 2026.</p>

Call it three cents. The free tier (the first 180,000 vCPU-seconds each month cost nothing) would shrink it further, and a build minute plus image storage adds a little back; the order of magnitude doesn't move. Fifteen active minutes is generous, by the way. In my experience a preview gets opened about twice: once by the author confirming it deployed, once by the reviewer forming an opinion.

That observation carries the whole economic argument. An environment billed by the second costs what it's actually used, and a preview is barely used, so a preview is barely billed. A staging server priced by the month inverts this, charging you for every hour nobody is looking at it, which is nearly all of them. Same compute. Different pricing physics.

The table also hides a floor worth naming: with request-based billing the instance is only allocated while serving traffic, so a preview's eleventh day of existence costs exactly what its first did, which is zero if nobody visits. Longevity is free. Only attention is billed.

## The lifecycle, and where it bites

```
open PR         -> build image -> deploy revision -> post URL on the PR
push new commit -> rebuild     -> replace revision (same URL)
no traffic      -> scale to zero
merge or close  -> destroy revision, DNS record, preview database
```

The first three lines are the demo. The fourth line is the product. Provisioning is a mostly solved problem with good primitives underneath it; teardown is where preview systems rot, because teardown's failure mode is silent. A missed webhook, a PR closed mid-deploy, a force-pushed branch rename: each one orphans an environment that sits invisible until someone finds it months later, still holding a database. So we treat reconciliation as the core loop, continuously comparing what should exist (open PRs) against what does exist (running previews), instead of trusting that every event arrived exactly once. Event-driven teardown is a rumor. Reconciliation is a fact.

Routing has a trap of its own. Every preview needs a working URL moments after push, and issuing a fresh TLS certificate per preview walks straight into [Let's Encrypt rate limits](https://letsencrypt.org/docs/rate-limits/) on a busy repository, so previews live under a wildcard certificate and a wildcard DNS record provisioned once. One early decision deletes an entire class of flaky waiting.

Isolation is the second bite. A preview executes branch code, and branch code hasn't passed review yet, so a preview that receives production secrets is a phishing kit you built for yourself. Preview environments get their own scoped credentials and their own data, never production's, and that rule costs us real convenience, because "test it against real data" is the most requested thing previews can't safely be.

Databases are the third bite, and the honest one. Stateless containers scale to zero gracefully; PostgreSQL does not, and the trade-off triangle is real: a schema-only database is cheap and safe but empty, seeded fixtures are useful but drift from reality, and a copy of production data is realistic and a compliance incident waiting for a fork. Our default sits at the cheap, safe end of that triangle, and one rule is absolute: production data never crosses into a preview.

## "That's not staging"

The strongest objection deserves its space: a preview with a seeded database won't catch the bug that only appears at production data shapes, won't carry a load test, and mocks the third-party integrations that break in the interesting ways. All true. A team that replaces capacity planning with preview environments will meet reality on a bad day.

But that objection compares instruments doing different jobs. Staging answers "does this survive production conditions"; a preview answers "is this the change we think it is", and it answers inside the review conversation, while opinions are still cheap to change. The expensive failure previews prevent isn't an outage. It's the LGTM that nobody actually looked at.

Around three cents buys a second opinion that loads in a browser. Next time someone says disposable environments are too expensive for your team, ask to see their arithmetic next to this table. Then ask what the last staging-slot conflict cost in engineer-hours, and compare columns.

---

Related: [Cloud Pricing That Makes Sense](/cloud/cloud-pricing-that-makes-sense), the pricing philosophy these previews are built on.
More about what we're building at [light-cloud.com](https://light-cloud.com).


The arithmetic, the machinery, and the part that rots

Anatomy of a 3-Cent Preview Environment


## What if deploying your entire stack was as simple as pushing to GitHub?

That's the question we asked ourselves when building Light Cloud. We were tired of the same story: you build an amazing app, and then you spend days configuring infrastructure. Setting up CI/CD. Wrestling with Docker. Figuring out how to connect your frontend to your backend to your database.

Today, we're launching Light Cloud, a deployment platform that handles all of it.

## A True Full-Stack Platform

Light Cloud isn't just another static site host. It's a complete deployment platform for modern applications. Frontend, backend, database, all in one place.

![Applications dashboard showing Node.js backends, static sites, and multiple environments](/assets/blog/introducing-light-cloud/applications.png)

Deploy Node.js, Python, Go, Java backends alongside React, Vue, Angular, Svelte frontends. Connect your GitHub and go.

### Every Framework, Every Runtime

**Static Sites**: React, Next.js, Vue, Angular, Svelte, plain HTML. We auto-detect your framework and build settings from your repository. Global CDN distribution included.

**Container Applications**: Node.js, Python, Go, Java, Ruby, PHP, .NET. Light Cloud generates Dockerfiles automatically for common runtimes, or bring your own. Configure CPU and memory to match your workload.

**Managed Databases**: PostgreSQL databases with automated provisioning, backups, and connection management. Spin one up in seconds, not hours.

## GitHub-Native Workflow

We built Light Cloud around how developers actually work:

- **Auto-deploy on push**: Every push to your tracked branch triggers a new deployment
- **Branch environments**: Push a new branch, get a new environment. Perfect for feature testing and PR previews
- **Auto-cleanup**: Delete a branch? We clean up the environment automatically (production is always protected)

![Deployment history with GitHub auto-deploy](/assets/blog/introducing-light-cloud/deployments.png)

Every commit deploys automatically. Full deployment history with commit links and status tracking.

Your deployment URL follows a predictable pattern: `{branch}-{app}-{org}.light-cloud.io`

Your `main` branch deploys to `main-myapp-acme.light-cloud.io`, and your `feature-auth` branch gets `feature-auth-myapp-acme.light-cloud.io`. No configuration needed.

## Real-Time Logs

Debug issues without SSH access. Stream logs from your containers in real-time, filter by severity, search across your entire log history.

![Live logs with severity filtering and search](/assets/blog/introducing-light-cloud/logs.png)

Searchable logs with timestamps, severity levels, and filtering. See exactly what your app is doing.

No more guessing why something failed. No more waiting for log aggregation. Just instant visibility into your running applications.

## Built-In Metrics Dashboard

Monitor your applications without setting up Prometheus, Grafana, or any other observability stack. Light Cloud tracks the metrics that matter:

- CPU and memory usage
- Request count and latency
- Active instances
- Bandwidth in/out

![Metrics dashboard showing CPU, memory, requests, and instances](/assets/blog/introducing-light-cloud/metrics.png)

Real-time metrics for every environment. Track performance, spot issues, understand your resource usage.

See exactly how your app performs, when it scales, and what resources it consumes. All built in.

## Scale-to-Zero by Default

Here's what makes Light Cloud different from traditional cloud providers: **you only pay when your app is running**.

Most platforms charge you 24/7 whether anyone is using your app or not. Light Cloud containers scale to zero when idle. That side project you're working on? It costs practically nothing until it gets traffic.

When a request comes in, we spin up your container in seconds. When traffic stops, we scale back down. Your bill reflects actual usage, not theoretical capacity.

## Pricing That Makes Sense

We believe in transparent, usage-based pricing. You control your wallet.

| Resource | Price | Real example |
|----------|-------|--------------|
| Container (Nano/Micro) | $0.03/hour | 1 hour test = three cents |
| Container (Small) | $0.03/hour | 100 hours = $3 |
| Database (Dev, shared) | pennies/hour | a few dollars/month |
| Static Site | $0.02/month | Six sites = twelve cents |
| Team Members | $9/user/month | |

**30-day free trial**: Up to 3 resources. No credit card required for the first two weeks. We show you exactly what your usage would cost, so there are no surprises when billing starts.

Scale-to-zero means your containers cost literally $0 when not running. Test environment for an hour? Three cents. Vacation month? Zero.

## Built for Developers Who Ship

Light Cloud is for:

- **Indie hackers** launching their next SaaS
- **Startups** that need production infrastructure without a DevOps hire
- **Developers** building side projects on weekends
- **Teams** wanting Vercel simplicity with container and database support

If you've ever wished you could just `git push` and have everything work, that's exactly what we built.

## Get Started in Minutes

1. Sign up at [console.light-cloud.com](https://console.light-cloud.com)
2. Connect your GitHub account
3. Select a repository
4. Click deploy

That's it. No Dockerfiles to write (unless you want to). No CI/CD pipelines to configure. No infrastructure to manage.

Your first deployment is live in minutes, not hours.


Introducing Light Cloud: Static sites, containers, and databases - all from your GitHub repo

Deploy Full-Stack Apps in Minutes


## What is ICE?

**Integrated Cloud Environment** is the world's first unified platform that brings together everything you need to build, deploy, and manage cloud infrastructure-all in one place.

Think of it this way: Just as Integrated Development Environments (IDEs) like Visual Studio revolutionized how developers write code by combining editors, compilers, and debuggers into one tool, ICE is revolutionizing cloud infrastructure by integrating architecture, deployment, monitoring, and security into a single visual platform.




## The Problem ICE Solves

If you've ever built cloud infrastructure, you know the pain:

**Disconnected Tools Everywhere**
You're juggling separate platforms for architecture diagrams, infrastructure deployment (Terraform, CloudFormation), monitoring (Datadog, CloudWatch), security scanning, and cost tracking. Each tool has its own learning curve, login, and interface.

**Unpredictable Costs**
You deploy infrastructure and hope the pricing calculator was accurate. Weeks later, you're hit with an unexpected bill. Sound familiar?

**Vendor Lock-In**
You built everything on AWS, but now you want to try Google Cloud or Azure. Good luck-you're essentially starting from scratch with new SDKs, authentication flows, and documentation.

**Weeks of Setup**
Setting up a production-ready microservices platform with proper monitoring, security, and CI/CD? That's weeks or months of work, even for experienced DevOps teams.




## How ICE Works

ICE integrates five critical components that are traditionally separated:

### 1. **Architecture**
Design your infrastructure visually using a drag-and-drop interface with standardized blocks. No more switching between diagramming tools and actual deployment.

### 2. **Infrastructure**
Deploy your architecture directly to any major cloud provider (AWS, Google Cloud, Azure) with a single click. ICE handles all the provider-specific complexity behind the scenes.

### 3. **Observability**
Get full visibility across your distributed systems with integrated logs, metrics, and traces-all in one dashboard, regardless of which services you're using.

### 4. **Security**
Built-in security best practices and compliance checks ensure your infrastructure meets industry standards from day one.

### 5. **Code**
Load predesigned architecture templates with connected code repositories, or integrate your existing codebase seamlessly.


## Key Features That Make ICE Different

### Visual Studio for Cloud
Design your infrastructure visually using standardized blocks and templates. If you can drag and drop, you can build enterprise-grade infrastructure.

### Live Cost Estimation
See real-time cost projections as you build. Change a server size or add a database? Watch the monthly estimate update instantly. No more surprise bills.

### Multi-Cloud Freedom: True Provider Agnostic Architecture

One of ICE's most powerful features is its cloud-agnostic approach. Unlike traditional infrastructure-as-code tools that lock you into provider-specific syntax and services, ICE uses standardized blocks that work across all major cloud platforms.

**What This Means For You:**

**Design Once, Deploy Anywhere**
Build your infrastructure using ICE's standardized blocks, then deploy to AWS, Google Cloud, or Azure without rewriting anything. The same architecture, the same configuration, different providers.

**Seamless Cloud Migration**
Already running on one cloud provider? ICE makes migration straightforward:
1. Import your existing infrastructure into ICE
2. Review and adjust the standardized architecture
3. Deploy to your target cloud provider

What traditionally takes months of rewriting infrastructure code, learning new provider-specific tools, and extensive testing can now be done in days.

**Avoid Vendor Lock-In**
Your business requirements change. Maybe AWS pricing doesn't work for your scale, or you need Google Cloud's specific AI services, or Azure's enterprise integrations. With ICE, switching providers isn't a multi-month project-it's a configuration change.

**Multi-Cloud By Default**
Run parts of your infrastructure on different providers simultaneously. Use AWS for your main application, Google Cloud for data processing, and Azure for enterprise integrations-all managed from one interface with unified observability.

**Provider-Specific Complexity, Abstracted**
Each cloud provider has its own:
- SDKs and APIs
- Authentication mechanisms
- Service names and configurations
- Networking models
- Security paradigms
- Documentation quirks

ICE handles all of this complexity for you. You work with standardized blocks, and ICE translates to provider-specific implementations automatically.

### Full System Visibility
Monitor everything from a single dashboard. Logs, metrics, traffic patterns, performance data-all unified and correlated, so you can actually understand what's happening across your entire system.

### Templates That Cover 80% of Use Cases
Start with proven, production-ready templates for common scenarios:
- Microservices SaaS platforms
- E-commerce systems
- Data processing pipelines
- API backends
- Mobile app backends

Customize as needed, or use them as-is.


## Who ICE Is For

### For Developers
Stop context-switching between tools. Build, deploy, and monitor from one interface. Spend more time coding, less time on infrastructure headaches.

### For DevOps Teams
Reduce the operational burden. ICE automates the complex setup and integration work, so you can focus on optimization and scaling instead of basic infrastructure management.

### For Startups
Launch faster. Get enterprise-quality infrastructure without needing a full DevOps team or months of setup time. Your MVP can have production-grade infrastructure from day one.

### For Non-Technical Founders
You don't need to be a cloud expert. ICE handles the technical complexity so you can focus on building your business. Launch your startup infrastructure in minutes, not months.


## From Months to Minutes: A Real Comparison

### Traditional Approach (Weeks to Months)
1. Research cloud providers and services (days)
2. Learn infrastructure-as-code tools (weeks)
3. Design architecture (days to weeks)
4. Write deployment scripts (weeks)
5. Set up monitoring and logging (weeks)
6. Configure security and compliance (days to weeks)
7. Test and debug everything (weeks)
8. Write documentation (days)

**Total: 2-4 months for experienced teams**

### With ICE (Minutes)
1. Choose a template or drag blocks to design
2. Configure settings
3. Deploy

**Total: 5-15 minutes**


## The Technology Behind ICE

ICE is built on a foundation of:
- Standardized, cloud-agnostic infrastructure blocks
- Real-time cost calculation engines
- Integrated observability pipelines
- Multi-cloud deployment orchestration
- Visual architecture design tools

All designed to work together seamlessly, so you don't have to make them work together yourself.


Dev Tools

Why We're Building a Desktop App in 2026

Anatomy of a 3-Cent Preview Environment

Deploy Full-Stack Apps in Minutes

Integrated Cloud Environment