> ## Documentation Index
> Fetch the complete documentation index at: https://mogenius-docs-self-hosted-helm-values-update.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-Environment Deployments

> Set up a multi-environment deployment strategy with dev, staging, and production using mogenius UI and GitOps.

A common pattern for production-ready applications is maintaining separate environments for development, staging, and production. mogenius supports this through a combination of UI-based deployments for rapid iteration and GitOps for stable, version-controlled environments.

**The recommended approach:**

* **Development**: Deploy and iterate quickly using the mogenius UI.
* **Staging and Production**: Enable GitOps to manage deployments declaratively through Git, with pull request-based reviews for production changes.

## Setting up a development environment

<Steps>
  <Step title="Create a workspace">
    Create a workspace for your development environment. Assign it to the cluster and namespace where your dev workloads should run. See [Creating Workspaces](/workspaces/creating-workspaces).
  </Step>

  <Step title="Deploy your application">
    Use any of the deployment methods to get your application running:

    * [Container images](/deploying-applications/container-images) for deploying from a registry.
    * [Pipeline starters](/deploying-applications/pipeline-starters) for CI/CD from a Git repository.
    * [Helm charts](/deploying-applications/helm-charts) for chart-based deployments.
  </Step>

  <Step title="Configure deployment settings">
    Set up environment-specific configuration for your dev environment: environment variables, resource limits, health checks, and scaling. See [Deployment Configuration](/deploying-applications/deployment-configuration).
  </Step>

  <Step title="Iterate and test">
    Use the built-in [monitoring and logs](/workspaces/service-status-and-errors) to debug and iterate on your application. The mogenius UI allows you to make changes and see results quickly without needing to manage YAML files or kubectl commands.
  </Step>
</Steps>

## Enabling GitOps for environment promotion

Once your application is working in development, enable GitOps to version-control your configurations and promote them to other environments.

<Steps>
  <Step title="Enable GitOps on your cluster">
    Navigate to your cluster settings and enable GitOps. This installs ArgoCD and Sealed Secrets on your cluster and connects a GitHub repository. See [GitOps setup](/cluster-management/gitops).
  </Step>

  <Step title="Create a GitOps application">
    Add your development deployments to a GitOps application. mogenius automatically generates the Kubernetes manifests and commits them to your Git repository. You now have a versioned, declarative representation of your application.
  </Step>

  <Step title="Your manifests are now in Git">
    All configuration changes you make through the mogenius UI are automatically committed to Git. This gives you a full history of changes and enables Git-based workflows for promoting configurations to other environments.
  </Step>
</Steps>

## Creating staging and production environments

With your application manifests in Git, you can set up additional environments using GitOps.

### Staging environment

Create a separate workspace with its own namespace for staging. Use GitOps to deploy from the same Git repository, ensuring consistency between development and staging. Adjust environment-specific settings (environment variables, resource limits, replica counts) as needed for the staging context.

### Production environment

For production, use GitOps with **pull request-based commit behavior**. This ensures that every change to your production configuration goes through a review process before being applied.

To enable this:

1. In your cluster's GitOps settings, activate the toggle for creating pull requests instead of direct commits.
2. When changes are made, mogenius creates a pull request in your Git repository.
3. Team members review and approve the pull request.
4. Once merged, ArgoCD syncs the changes to the production cluster.

<Tip>
  Using pull request-based commits for production environments enforces code review on all infrastructure changes, providing an audit trail and preventing accidental configuration changes.
</Tip>

## Alternative: ApplicationSets for existing Git configurations

If your team already maintains Kubernetes manifests, Helm charts, or Kustomize overlays in Git, you can use **ApplicationSets** instead of the workspace-based approach described above. ApplicationSets deploy directly from your existing Git repository structure.

This approach is useful when:

* You have an established GitOps workflow with manifests already in Git
* You use Kustomize overlays for environment-specific configurations (e.g., `overlays/dev`, `overlays/staging`, `overlays/prod`)
* You want to manage environment differences through Git rather than the mogenius UI

To set this up:

1. Enable GitOps on your cluster and connect your manifest repository
2. Create an ApplicationSet for each environment, pointing to the appropriate overlay or values file
3. Use Kustomize configuration options (namespace overrides, name prefixes, image overrides) to differentiate environments

For example, with a Kustomize-based repository:

* **Dev ApplicationSet**: Path `apps/my-service/overlays/dev`, Kustomize Namespace `development`
* **Prod ApplicationSet**: Path `apps/my-service/overlays/prod`, Kustomize Namespace `production`, Name Prefix `prod-`

See [ApplicationSets](/cluster-management/gitops#applicationsets) for detailed configuration options.

## Managing environment-specific configurations

When running multiple environments, keep these practices in mind:

* **Use separate namespaces** for each environment to isolate resources and prevent conflicts.
* **Environment variables**: Set different values per environment (e.g., database URLs, API endpoints, feature flags) in each workspace's [deployment settings](/deploying-applications/deployment-configuration).
* **Resource limits and scaling**: Development environments typically need fewer resources and replicas than production. Configure appropriate [resource limits and scaling](/deploying-applications/deployment-configuration#horizontal-scaling) per environment.
* **Secrets**: Manage environment-specific secrets through the Secrets & Configs page in each workspace. When GitOps is enabled, secrets are encrypted with [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) before being committed to Git.
* **Workspaces as team boundaries**: Use [workspace roles](/workspaces/members-and-roles) to control who can make changes in each environment. For example, give developers editor access to dev but only viewer access to production.