Application Blueprints
Application Blueprints are the way you define applications in Atmosly. A blueprint captures everything needed to build and deploy an application — its source, build settings, environment variables, and deployment configuration — so it can be deployed consistently across environments and reused over time.
Open it from Application Blueprint in the left navigation menu.
Application Blueprints are the evolution of the older Projects model. Applications are now the primary unit you work with, and Projects act as organizational groupings that bundle related applications together.
The List Screen
The list screen has two views you can toggle between:
Applications view
Lists every application blueprint with these columns:
| Column | Description |
|---|---|
| Name | The application name (links to its details). |
| Source | Where the application comes from — Git repository, container registry, or data source. |
| Repository | The source repository or image. |
| Environments | The environments the application is deployed to. |
| Projects | The project(s) the application belongs to. |
| Owner | The application's owner(s). |
| Created | When it was created, and by whom. |
You can search by name and filter by source, environment, project, and owner. Applied filters appear in a filter bar that you can clear individually or all at once.
Projects view
Lists the projects that group your applications, showing the service count, labels, environments, and created/updated details. Selecting a project opens its details, where you can see and manage the applications it contains.
Creating an Application Blueprint
Click Create Application Blueprint and complete the guided, tabbed form. The available fields adapt to the source type you choose.
1. Basic Details
| Field | Description |
|---|---|
| Application Name | A unique name. Atmosly warns you if a similar name already exists. |
| Source Type | Git Repositories, Container Registry, or Data Sources. This determines the build options in the next step. |
| Associated Projects | One or more projects to group the application under. You can create a new project inline without leaving the form. |
| Application Owners | The owning user(s). Your own user is selected by default. |
| Application Labels | Optional key-value labels (up to five). |
| Description | An optional description. |
2. Build Configuration
The fields depend on the source type:
- Git Repositories — choose the Git provider and repository, the default branch, the Dockerfile path and build context, target architecture, build resources, and the container registry to push the built image to.
- Container Registry — provide the image repository and tag, and whether the registry is public or private.
- Data Sources — build configuration is not required; the data source is configured in the deployment step.
3. Environment Variables
Add the variables your application needs, choosing for each whether it's a plain value, a config map, or a secret, and whether it's injected at build time, run time, or both. You can also connect an external secret manager for storing sensitive values.
4. Deployment Template
Define how the application is deployed. For most applications you can use the Visual editor to set service exposure (public or internal), replicas, resource requests and limits, ports, health-check path, and volumes — or switch to YAML to edit the manifest directly (and Helm for container-based apps). For data sources, you instead choose the engine (MySQL, PostgreSQL, MongoDB, or Redis) and its version and resources.
Your progress is saved as you go, so you won't lose your work if you navigate away and come back while creating a blueprint.
Editing a Blueprint
Opening an existing application gives you the same tabs as creation, plus two more:
- Workflows — the CI/CD workflows attached to the application. From here you can open a workflow or Add Workflow to create a new one (see Workflows).
- Environments — the environments the application is deployed to, with links to each environment and its cluster.
The Source Type is fixed once a blueprint is created. Other fields, including build, variables, and deployment settings, can be updated at any time.
Attaching Workflows
Workflows connect an application to a cluster and environment for build and deployment. To add one, open the application, go to the Workflows tab, and choose Add Workflow. You'll name the workflow, select the target cluster, and then design its stages. For full details, see the Workflows documentation.
Permissions
Working with Application Blueprints requires the relevant project permissions on your role. Contact your organization admin if you can't see or create blueprints.