Copied from the last job
- The pipeline exists in Slack and a gist.
CI/CD that is born with the repo — and stays in the repo
A working pipeline costs days nobody writes down. Next project you hunt for the file. We create GitLab CI with the wizard. After that it is yours. You may edit it.
- Test, build, publish, release — prepared, not hidden
- The file lives in git. Special cases you edit, instead of opening a ticket.
Folklore or a file in git
Born with the project
- GitLab CI comes with the template. After that it is your YAML.
Pipeline for Customer App
test
build
publish
release
Automating CI/CD is not buying a dashboard of green ticks. It means test, build and release exist as a file in the repo before the team argues whose laptop is currently green.
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 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 once you connect your account under Connections, with errors 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 9 September 2026. This comparison describes typical workflows and can differ from project to project. Logos are trademarks of their owners and are used only to identify the product.
Not a black box
- You may change it The file lives in the repo. If you need special cases, you edit it — that is the point, not a gap.
Pricing model
Runners and pipeline belong to the project. There is no second CI vendor just for builds.
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?
Project credentials and environment variables are managed centrally and made available to the pipeline without ending up in files in the repository. Deploy keys and CI variables are created with the repository, and roles govern who can access them.
How do I see what is live?
Deployments appear as release cards per repository, so what is rolled out is directly readable. Environments live as configuration in Git history, making runtime changes traceable. When something breaks, Sentry attributes the error to a release.
Can I publish packages from the pipeline?
Yes: Docker images, Terraform providers and modules, and packages for Go, Python, NPM 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.