Environments

Overview

An environment is an isolated configuration scope within a project. Each environment has its own set of module instances, ACL rules, flux scripts, and templates, but they all share the same project’s data model definition. Environments let you develop and test changes locally before pushing them to staging or production, without risking data collisions between scopes.

When you create a project, Oblax provisions a default environment. You can add additional environments for different stages of your release pipeline — for example, development, staging, and production.

How Environments Work

Each environment maintains its own copy of your application resources. The local /app filesystem represents your current working environment. When you push or pull, you operate on one environment at a time.

/app
  /forms        → Environment-specific form definitions
  /bookmarks    → Environment-specific bookmark definitions
  /flux         → Environment-specific flux scripts
  /templates    → Environment-specific templates
  /acl          → Environment-specific ACL rules

Environment configuration is stored in your project’s oblax.json manifest and can be overridden per environment using flags or environment-specific configuration files.

Environment Types

Switching Environments

You can switch between environments using the CLI:

obx env use staging

Or specify the environment inline for a single command:

obx app forms list --env production

Environment Isolation

Each environment is fully isolated. Changes made in one environment do not affect others unless you explicitly sync them. This isolation applies to:

• Module definitions (forms, bookmarks, templates)
• Flux scripts and event handlers
• ACL rules and permissions
• Client configurations

When you promote changes from development to staging, you push the local definitions to the target environment. The platform stores each environment’s resources separately, ensuring no cross-contamination.

Where to next