Environment
An Environment exists within a Project and represents a fully isolated deployment boundary. Each Environment contains its own set of services, configuration, and infrastructure settings — completely independent of every other Environment.
What is an Environment?
A Project can contain multiple Environments, typically aligned with stages of your software lifecycle — dev, test, staging, and production. Each Environment contains its own set of deployments and services, and is completely isolated from other Environments. This allows you to promote releases across stages with confidence, knowing that nothing in one Environment can affect another.
In short, an Environment represents where and how your system is deployed.
Per-Environment Configuration
Every Environment is fully independent — not just in what it runs, but in how it is configured. You can tune each stage to match its purpose without affecting any other.
Domain Names
Every Environment is automatically assigned a DNS name on the modstack.dev domain. This gives you a publicly reachable endpoint out of the box, with no configuration required.
To use your own domain name, while creating the environment choose to add a CNAME record pointing your desired hostname to the assigned ModStack address. For example, you could point app.mydomain.com to xxx.app.modstack.dev. SSL certificates are provisioned and renewed automatically for custom domains.
Networking & Security
Apply environment-specific firewall rules, private networking, and security policies without affecting other stages.
Private Networking
All services and modules deployed in an environment can communicate with each other over a private network. Services address each other using their service name, which is DNS-compatible — so reaching another service is as simple as calling http://my-service. No public endpoints, no manual IP management, no configuration required.
Egress Firewall
Control the outbound connectivity of your services to the internet. By default, egress is open — services can reach any external endpoint. For tighter control, you can lock it down to only allow outbound access to a whitelist of DNS names. This is useful for compliance-sensitive environments where you need to guarantee that services only communicate with approved external dependencies.
Supported Architectures
Configure which CPU architectures are supported for each Environment. By default, both amd64 and arm64 are enabled — meaning builds produce multi-arch images that run on either platform.
For development environments this is often unnecessary. If your laptop is x64, you can turn off arm64 builds — or vice versa if you are on Apple Silicon. Production environments typically keep both enabled so that workloads can run on whichever instance type is most cost-effective.
Disaster Recovery Coming soon
Automatically set up a replica of your environment in a different region or cloud with a single click. Choose between Active-Active or Active-Passive deployment styles to match your availability and consistency requirements.
Developer Environment (Local Mode)
ModStack also supports a special Developer Environment that runs on a developer's laptop. It provides a full-fidelity local development experience while preserving the same deployment model and configuration used in the cloud — so there is no gap between what you run locally and what gets deployed.
Local Mode mirrors cloud deployment behaviour, uses the same configuration model as every other Environment, and allows developers to test offline or iterate rapidly without changing architecture assumptions.
The goal of Local Mode is to eliminate the gap between local development and cloud deployment, ensuring consistency across the entire lifecycle.