Development environment: what it is and how to set one up

A development environment is the collection of software, configuration, and computing resources you use to write, run, and debug an application. It includes the language runtime or compiler, dependencies, development tools, and any services the application needs. It can run on your laptop, a remote server, or a cloud instance.

A useful setup lets you test a change, understand a failure, and recreate the same working conditions later. This guide explains the main options, how development differs from staging and production, and how to build a repeatable setup without adding tools you do not need.

What belongs in a development environment?

The application determines the requirements. A static website may need a code editor, a browser, and a build tool. A web application might also need a database and a background worker. A machine learning project adds libraries, datasets, and sometimes GPU resources.

Record the operating system and processor architecture, programming language version, package manager, dependencies, and configuration. Include commands for starting services, building the application, running unit tests, and debugging. Version control connects this setup to the source code and its history, so multiple developers can work from a shared baseline.

Development environment vs. integrated development environment

An integrated development environment, or IDE, brings coding tools into one interface. Typical features include a source code editor, syntax highlighting, code completion, a debugger, and build or test integration. The AWS explanation of IDEs describes these common components.

The IDE is one part of the wider development environment. Installing an editor does not necessarily install the runtime, database, or system libraries your project needs. Visual Studio Code can gain language and debugging support through extensions; a notebook provides another interface for running code and inspecting results. Choose tools that support the project and your team's workflow.

For example, a web development project might combine a local code editor, a language runtime, a database, and build automation tools. A project using multiple languages needs the appropriate tools for each. Syntax highlighting helps distinguish code elements, while language-aware diagnostics can flag syntax errors; neither replaces running the program and checking its behavior.

Development, testing, staging, and production

These names describe the purpose of an environment, not where it is hosted. A development environment can be remote, and a production environment can run on premises. Teams may combine some stages or create temporary environments for individual changes.

Environment	Main purpose	What to control
Development	Write code, investigate behavior, and try changes	Dependencies, test data, and access to external services
Testing	Run automated or manual checks	Repeatable inputs, expected results, and test isolation
Staging	Check a release in conditions resembling production	Relevant configuration, integrations, and deployment steps
Production	Serve real users and workloads	Availability, security, monitoring, and recovery

Keep development credentials separate from production credentials. A local application can still send a real email, charge a payment method, or modify a live database if its configuration points there. Use sandbox services and synthetic or appropriately sanitized data. Calling an environment “development” does not make its actions harmless.

Consider a checkout change in the software development process. A developer edits it locally, an automated testing environment checks expected behavior, and a staging environment exercises the payment integration with test credentials. Quality assurance may also check the user journey before the team deploys the release to its live environment. The exact steps depend on the application and its risks.

Choose where your code runs

Local development environment

Local development runs the application on your own machine. It gives you direct access to files and hardware, and it can work offline when required dependencies and services are available locally. It is a practical starting point for learning, small applications, and projects that fit your computer's resources.

Differences between machines need attention. An application developed on one processor architecture may use a dependency unavailable on another. Document supported platforms, avoid relying on undocumented global packages, and check that a fresh checkout works for another developer.

Remote and cloud development environments

With remote development, the application runs on another machine while you work through an editor or terminal. Visual Studio Code Remote SSH, for example, connects a local editor interface to a remote environment. This can give a laptop access to more memory, a different operating system, or a GPU.

A managed cloud IDE adds hosted environment creation and management. GitHub Codespaces uses a development container on a Linux virtual machine, with browser and supported editor access. Check the service's operating systems, access controls, lifecycle, and billing before adopting it.

Remote development depends on connectivity and access to the host. Decide where source files, datasets, and outputs persist. Long-running work also needs a suitable job runner or session arrangement; closing your laptop is not a guarantee that a process will continue or that its results are saved.

Containers and virtual machines

Containers and virtual machines can run locally or remotely. A container packages an application environment while sharing its host's kernel. A virtual machine has a guest operating system and its own kernel. The Docker introduction to containers explains this distinction; our VM and container comparison considers it for machine learning workloads.

Containers help standardize dependencies, but they do not make all machines identical. Processor architecture, host drivers, mounted files, and external services can still change behavior. A Python virtual environment has a narrower role: it separates Python packages. It does not supply a separate operating system or a security boundary for untrusted code.

Set up a repeatable development environment

Start with a small working application and make the setup repeatable before adding more services. The following sequence works for individual projects and gives a team a basis for onboarding.

1. Define the requirements. List the supported operating systems, language version, memory, storage, and services. Identify any architecture or GPU constraints before choosing the host.
2. Save the setup specification. Keep dependency manifests, supported version information, and setup instructions in the source repository. Use lock files where the package manager supports them. Record required environment variable names without storing secret values.
3. Isolate project dependencies. Use the language's environment tools or a container when appropriate. Recreate Python virtual environments from the specification instead of copying the environment directory between machines.
4. Configure services and test data. Create development accounts and databases, load a small representative dataset, and restrict network exposure. Make the safe default clear in the configuration example.
5. Define build and test commands. Document how to start the application, run unit tests, inspect logs, and attach a debugger. Run equivalent checks in continuous integration so failures do not depend on someone remembering a manual step.
6. Test a clean setup. Rebuild from a fresh checkout or a new environment. Ask another developer to follow the instructions, then fix missing steps and record how to update or remove the setup.

For a container-based workflow, a development container configuration can describe the image, editor extensions, and setup commands. Keep development conveniences separate from production requirements: a production image may not need a debugger or the full build toolchain.

Make dependency updates deliberate. Image tags can change; pinning a digest identifies a particular image but also means arranging updates yourself. Docker's build guidance covers this tradeoff. Review and test updates regularly instead of treating a frozen environment as permanently safe.

Assign someone to maintain this configuration management process. When a dependency changes, update the specification and verify the clean setup again. Judge developer productivity through practical friction, such as setup time and recurring environment failures, rather than the number of tools installed. A new developer should be able to identify the supported path and where to report a problem.

When does development need a GPU?

Many programming tasks, tests, and data preparation jobs run on a CPU. Add a GPU when the workload uses an accelerated library and the expected benefit justifies its cost. Model size, batch size, and intermediate data affect memory needs; a GPU name alone does not establish whether a workload fits.

For machine learning, follow the framework's supported installation path. The PyTorch installer guidance distinguishes operating systems and compute platforms. Verify the chosen installation with a small computation and a device check before starting a large run. Building custom extensions may require additional compiler and toolkit compatibility checks.

A GPU container also needs a compatible host driver and container runtime configuration. The NVIDIA Container Toolkit installation guide sets out these host requirements. Installing a container image alone does not give it access to a GPU.

Compute with Hivenet offers remote CPU and GPU resources for suitable development workloads. Check the instance options against your setup: container instances have managed system packages and no root access, while virtual machines provide sudo access and operating system control. Confirm current availability and pricing before allocating resources.

Troubleshoot differences between environments

When code works on one machine but fails on another, compare the actual configuration before reinstalling everything. Capture the error, the failing command, and the relevant versions without exposing credentials.

Symptom	First checks
A package appears installed but cannot be imported	Check which interpreter and environment the editor and terminal use
The application cannot reach a database	Check whether the service is running, its address, network access, and credentials
A dependency fails on another computer	Compare processor architecture, operating system, runtime, and system libraries
Tests produce different results	Compare configuration, input data, time zones, and dependency versions

Include an environment summary in bug reports so someone else can reproduce the failure. Keep a known working setup available while diagnosing changes, and update the setup instructions when the fix reveals a missing requirement.

Control access, cost, and recovery

Give each developer the access needed for their work, protect credentials, and remove access when it is no longer required. Bind development services to appropriate interfaces or use controlled tunnels instead of exposing them publicly by default.

For remote resources, track running instances and retained storage separately. Stopping compute may leave billable disks, snapshots, or other services. Use budgets or alerts where available and make cleanup part of the workflow. Save code in version control and back up data and outputs separately; a reproducible environment does not replace a recovery plan.

Common questions

Do I need an IDE to develop software?

No. A text editor and command-line tools can be sufficient. An IDE is useful when its debugging, navigation, and build integration suit the project. The runtime, dependencies, and configuration are still necessary whichever interface you choose.

Should development exactly match production?

Match the parts that affect application behavior, such as runtime versions, services, and relevant configuration. Development may use debugging tools and smaller datasets. Staging and automated deployment checks help test differences that a local setup cannot reproduce.

What is the best starting point for a small team?

Use the simplest supported setup that everyone can recreate. Document one working path, automate repeated setup steps, and test it from a clean checkout. Add remote resources, containers, or orchestration when a specific requirement makes them useful.