Heads up! This article was written before Webiny 6.0 was released and may contain outdated information.
Webiny is the AI-programmable CMS that gives enterprises full control. Build, extend and automate your content operations with a platform designed to be shaped by both developers and AI agents.
A local development environment is a setup on a developer’s laptop or desktop that includes the necessary tools and services, like web servers, databases, and programming languages, to build and test applications locally.
LDEs allow developers to work offline, debug easily, and see code changes immediately without needing to upload files to a server. They provide fast feedback loops and are great for solo development.
LDEs can be complex to set up, resource-intensive, inconsistent across teams, and may require developers to reinvent features that could be better served by cloud-based or third-party solutions.
Modern applications increasingly rely on third-party and cloud-native services that cannot be replicated locally. This limits the usefulness of local development and leads teams to adopt serverless and cloud-native workflows instead.
Serverless development allows developers to build applications by using third-party services via APIs, eliminating the need to manage infrastructure. It enables scalable, secure, and performant apps—without depending on local setups.
In a cloud-native setup, most of the development and testing happens directly in the cloud. The only local tool might be the code editor, with all services running remotely and accessed via APIs.
While traditional debugging tools may not apply in the same way, modern cloud-native development offers its own set of tools, including remote logging, monitoring, and real-time testing frameworks.
Not necessarily overnight, but the trend shows that cloud-native, serverless approaches are quickly becoming the default for teams focused on scalability, security, and speed. Local development will continue to fade in importance as tools mature.
Serverless infrastructure is changing the way we architect applications and it’s also changing the way we code and work as developers. The development is moving away from our laptop and into the cloud. It’s the start of cloud-native development.
We at Webiny have been practicing cloud-native development for over a year now, and we believe this is the future. In this article, I will explain why.
A local development environment (LDE) is a way of configuring services on our laptop/desktop to run a website or a web application. This entails installing a web server, a database, and some sort of a language as Node.js, Python, PHP, and others.
This combination we call a stack. Some of the popular stacks are LAMP (linux-apache-mysql-php), MEAN (mongodb-express-angular-node) and others. Today you find these stacks preconfigured as Docker containers. This way you don’t “pollute” your machine with services as they run inside a container.
For years installing these stacks was the first thing a developer would do before checking out some code from git and running it. A local stack has several advantages. One of the main ones is that you can work offline. This is possible because all the services run locally on your machine, there is no need to fetch any data from “outside” the network.
Another meaningful advantage is the simplicity of debugging. If your code, database, or network is not working, you access those components directly and try and find the problem. You attach debuggers, inspectors, and profilers along the way to gain additional insight.
Lastly, with a local development environment, each time you change a file there is no need to upload it to a remote server. The moment you save the code it gets compiled locally and you instantly see the result. It provides a faster turnaround time.
Let’s review some of the disadvantages because it’s not all ideal when it comes to having an LDE.
When working in a larger organization the LDE can be large and complex. These environments take a lot of time to get them up and running. When they break, you often need to run the whole setup from the ground up.
You are also limited to a fixed number of containers and services you are able to run locally. This is because of the constraints to your CPU and memory. Try having 10 or more Docker containers running in parallel, it will significantly impede the performance of other apps, like your IDE for example.
Because not everyone has an identical setup, there are differences in how things work. This causes inconsistencies in testing, security, and performance. Those can later cause serious problems. When using an LDE with a team, you need to ensure everyone has the same stack, version and is always updating it with the latest releases.
Another limitation is you can’t use a closed source or 3rd party services. This is because, in most cases, they don’t provide a way of running their service locally. To keep an LDE, with all the previously mentioned advantages, you might decide not to use a 3rd party service but develop something internally you own. Over time you’ll make several of such decisions which end up wasting a big chunk of your time maintaining them.
This last one is the key reason why a local development environment is dying. — Let me explain.
Development is complex. Over time some of those complexities were solved and solutions were created as new products. Products that all other developers can now use and integrate into their applications. By using those products and services, instead of reinventing the wheel, developers save a lot of time and money, and create more resilient and secure solutions.
Let’s take a search engine for an eCommerce website as an example. Coding one is a daunting challenge. You might not have the right expertise in data storage and know the most optimal languages to code such a feature. Luckily services such as
When you test for resiliency and scale even the simple tasks, such as file storage, can pose a challenge to code from the ground up. Try and achieve 99.999999999% uptime that AWS S3 provides.
Many such examples are available, but the main takeaway is those services are not available inside an LDE. Serverless services in the majority of cases can only be consumed via an API contacting the service in the cloud.
The question is now — would you sacrifice having an LDE over a proven, performant and secure service with SLAs?
Many developers and businesses have answered NO. This is what’s driving the adoption of building solutions in a serverless way.
With serverless, there are servers behind those services, but you don’t care about them. The infrastructure is managed for you, including all the security patches and backups.
Developing applications the serverless way changes how we configure our LDE. We can no longer work offline and run services from our laptop.
Even if we get a part of the services running locally, it’s not a solution. LDE can’t emulate the network of a cloud setup, not to talk about API limits and performance.
Because the LDE is no longer reliable, in my view, the only way forward is to embrace cloud-native development. Our code needs to run in the cloud and the cloud is now part of our development environment and not just the production. The only remaining thing which is running “locally” will be our editor.
It’s clear that LDE is dying, and we won’t miss it. As a tradeoff, we get to create performant, scalable, resilient, reliable, and secure applications in less time. The industry is moving in that direction. There is still a way to go to make it a pleasant experience, but it is certainly coming.