Creating Apps

Apps are configured directly in the database. Each app maps a source repository to one or more named deployment environments.

1. Register the App

Insert a row into the apps table for each application repository:

Field	Type	Description
gitProvider	'gitlab' | 'github'	Git hosting provider
repoUrl	string	Repository URL (e.g. https://gitlab.com/org/app)

INSERT INTO apps (git_provider, repo_url)
VALUES ('gitlab', 'https://gitlab.com/org/my-app');

2. Add an IAC Repository

If you haven't already, register the IAC repository where charts will be pushed:

INSERT INTO iacs (name, repo_url, access_token)
VALUES ('prod-iac', 'https://gitlab.com/org/iac-repo.git', 'your-access-token');

The access token is encrypted at rest. See IAC Repositories for details on token setup.

3. Add a Cluster

If you haven't already, register the Kubernetes cluster DAG will monitor:

INSERT INTO clusters (name, api_url, service_account_token, ca_cert)
VALUES ('prod-1', 'https://k8s.example.com:6443', 'your-sa-token', 'your-ca-cert');

See Clusters for service account and CA certificate setup.

4. Create an App Environment

Map a branch and environment name to an IaC repo path and one or more cluster targets:

Field	Type	Description
appId	number	Foreign key to App
branch	string	Git branch that triggers deployment
name	string	Target environment name
iacId	number	Foreign key to IAC Repository
iacPath	string	Path within IAC repo to place the chart
iacBranch	string | null	IAC repo branch (null = default branch)

Add a target for every cluster that should receive the chart. A target has clusterId, helmType, helmNamespace, helmName, and an optional monitorTimeoutSecs rollout budget. DAG monitors every target in parallel and reports success only if all targets succeed. Set the rollout timeout in seconds on each target in the environment editor, or supply monitorTimeoutSecs in that target's API input. Leave it blank/null to use the server default. DAG snapshots the resolved budget when a deployment is submitted, so edits apply to future deployments. See Target Rollout Budgets.

INSERT INTO apps_environments
  (app_id, branch, name, iac_id, iac_path, cluster_id, helm_type, helm_namespace, helm_name)
VALUES
  (1, 'main', 'production', 1, 'clusters/production/my-app', 1, 'flux', 'default', 'my-app');

Multiple Environments

You can map multiple branches to different environments. For example, deploy develop to staging and main to production:

-- Staging
INSERT INTO apps_environments
  (app_id, branch, name, iac_id, iac_path, cluster_id, helm_type, helm_namespace, helm_name)
VALUES
  (1, 'develop', 'staging', 1, 'clusters/staging/my-app', 1, 'flux', 'staging', 'my-app');

-- Production
INSERT INTO apps_environments
  (app_id, branch, name, iac_id, iac_path, cluster_id, helm_type, helm_namespace, helm_name)
VALUES
  (1, 'main', 'production', 1, 'clusters/production/my-app', 1, 'flux', 'production', 'my-app');

You can also map the same source branch to multiple environments. This supports CI workflows where main deploys to staging automatically and an approved production job promotes the same commit:

-- Staging from main
INSERT INTO apps_environments
  (app_id, branch, name, iac_id, iac_path, cluster_id, helm_type, helm_namespace, helm_name)
VALUES
  (1, 'main', 'staging', 1, 'clusters/staging/my-app', 1, 'flux', 'staging', 'my-app');

-- Production from main
INSERT INTO apps_environments
  (app_id, branch, name, iac_id, iac_path, cluster_id, helm_type, helm_namespace, helm_name)
VALUES
  (1, 'main', 'production', 1, 'clusters/production/my-app', 1, 'flux', 'production', 'my-app');