Four stages, one path
Test, build, publish and release follow the same route, so manual steps in between disappear.
Solution
CI/CD automation you do not have to rebuild for every project
Getting test, build, publishing and deployment to cooperate takes days, and the next project starts from scratch. The platform creates the pipeline with the project and leaves the configuration yours.
- Test, build, publish and release in a prepared GitLab CI pipeline
- Configuration lives readably in the repository and stays editable
- Deployments shown as release cards per repository
Start for free. No credit card required.
Pipeline for Customer App
test
build
publish
release
In short
The pipeline is created with the project, belongs to you, and reaches all the way to deployment.
- Four stages from day one: test, build, publish and release come prepared, not assembled after the fact.
- Not a black box: the GitLab CI configuration sits in your repository, readable and editable.
Building the pipeline yourself versus starting with the platform
This shows the work a continuous delivery chain creates and how much of it the Application Platform brings along.
| Task | With the Application Platform | Set up manually |
|---|---|---|
| Getting a first working pipeline | Fully covered: Created with the project, covering test, build, publish and release | Not offered: Write the configuration from scratch and debug it in circles |
| Runners and build environment | Fully covered: Build infrastructure is available, including macOS machines for iOS | Not offered: Provide, update and monitor runners yourself |
| Credentials inside the pipeline | Fully covered: Project credentials and CI variables are managed centrally | Partly covered: Maintain secrets per repository, with rotation quietly forgotten |
| Deploying to servers | Fully covered: Servers are connected with Docker, reverse proxy, SSL and backups in place | Not offered: Own the deploy scripts, SSH keys and server maintenance |
| Versioning | Fully covered: Versions and build numbers are produced by the pipeline | Partly covered: Set by hand or by a script somebody wrote once |
| Publishing packages | Fully covered: Docker images, Terraform, Go, Python, NPM, Composer, Maven and Dart with visibility per level | Partly covered: A registry per format and permissions maintained separately |
| Mobile releases to stores | Fully covered: Signing, store metadata and upload through Fastlane are part of the chain | Not offered: A separate process next to the pipeline, usually with manual steps |
| Traceable environments | Fully covered: Environments and deployments live as configuration in the Git history | Not offered: Server state accumulates over time and is hard to evidence |
| Overview of deployments | Fully covered: Release cards per repository show what is currently rolled out | Partly covered: Search pipeline logs or ask around in the team |
| Linking errors to a release | Fully covered: Sentry is set up, and errors are visible filtered by repository | Partly covered: Wire up error tracking separately and correlate it with releases |
Green means fully covered, amber partly, grey not offered. A hand-built pipeline can do the same; the difference is the effort per project.
As of 10 August 2026. This comparison describes typical workflows and can differ from project to project.
What a prepared pipeline changes
Less setup, more repeatability, better traceability.
Configuration in the repository
The GitLab CI configuration is readable inside your project and gets reviewed and versioned like code.
Versioning without follow-up
Version numbers and artifacts are produced by the pipeline and match the state of the repository.
Deployments in view
Sentry is fully set up so production errors show up in the platform with context attached.
configurations/prod/versions.yaml
application:
backend_configuration:
image_tag: 0.26.8-98
frontend_configurations:
customer-frontend:
image_tag: 0.15.6-80
admin-app:
image_tag: 0.12.1-42-
Customer app — -
Admin app — -
Backend —
The path from commit to deployment
Four steps that feel the same in every project.
-
Create the project
Pick your stack. Repository, project structure and a matching CI/CD pipeline are created together.
-
Connect a server
Attach your own server over SSH or use a managed one. Docker, reverse proxy, SSL, firewall and backups get configured.
-
Commit and merge
The pipeline tests, builds and publishes by the same rules no matter who triggers the merge.
-
Trigger the rollout
Kick off the deployment from the platform. The rolled-out state appears as a release card on the repository.
Frequently asked questions
Do I have to write the pipeline myself?
No. Creating a project produces a GitLab CI pipeline for test, build, publish and release that matches the stack you chose. You can use it as it stands or change it at any point, because the configuration lives readably in the repository.
Which technologies are covered?
The templates include Next.js, NestJS, Laravel, FastAPI, Flutter, Expo, native iOS and Android projects as well as Astro and Hugo. All ship through the same mechanism, and for mobile releases, store publishing through Fastlane hangs off the same chain.
How are credentials handled in the pipeline?
Yes: Docker images, Terraform providers and modules, and packages for Go, Python, NPM, Composer, Maven and Dart. For each artifact you decide who may consume it: the project, your organisation, all platform users, or the public.
Watch the pipeline run in your own project
Register for free, create a project and follow the first run from test through to deployment.
Start for free. No credit card required.