CI/CD Pipeline
Push your code and ship the exact release you tested
Every push is built in minutes and comes up in a test environment, and production receives the very image you tried, never a rebuilt copy. If a release goes wrong, image and configuration roll back together.
Why now
- A release that behaves in test misbehaves in production, because production gets a build of its own. On this pipeline, production runs a digest-verified copy of the image you tested.
- A Friday-evening release stopped orders, and finding the old configuration took an hour. The pipeline treats a failed release as a failure straight away and restores the previous image and configuration together.
- Nobody can say who released what or when, because deployments are files copied to a server. Here every change is a commit, and release rights belong to a defined release team.
- The operating system layer under your images has gone unpatched for months and the scanner is all red. The pipeline refreshes that layer every week without touching your application code.
- A new developer joins the team and needs help from three people to ship a first change. On the pipeline a push is enough, and the application comes up in test at its own address.
What changes
| Today | With Nesnet |
|---|---|
| Production gets its own build, and bugs that never showed in test appear in production. | Production runs a digest-verified copy of the tested image, so the only difference between environments is configuration. |
| After a bad release, someone digs up the old configuration by hand. | The previous image and configuration are restored together, and production is confirmed to be answering again. |
| Who released what, and when, is anyone's guess. | Every change is a commit and every release an append-only record, so you show the auditor your git history. |
| The OS layer under your images stays unpatched until someone remembers. | A patched layer is slid under every image each week, with no work asked of developers. |
| A new project means a week of server and permission requests. | The project is registered, its environments and runner are ready in minutes, and the first push lands in test. |
From today to live: how it works
- 1
Agreeing the scope
Settle with Nesnet's team in one call which repositories join the pipeline, where the test and production environments live and who sits on the release team.
- 2
Registering the project
Nesnet registers the project on the platform, and its namespaces, quotas, network policies, registry area and runner are ready within minutes.
- 3
First push
A developer pushes to GitHub; the built image goes to the private registry and the application comes up in test at its own address.
- 4
First release
The release team promotes the version tried in test, and the same image is copied to production with its digest verified and goes live within minutes.
- 5
Current every week
The operating system layer is refreshed every week and dependency updates arrive as pull requests. Your team only approves major version moves.
What you get
Every push lands in test
Every git push is built and deployed to the test environment, and the application's address responds within a few minutes. Developers see their change running without asking anyone to deploy it or waiting on a ticket.
The image you tested is the one that ships
The release in production is a byte-for-byte copy of the test image, made by its digest into the production area. The digest is checked again after the copy, and an image that fails the check never reaches production while the running release stays in place.
Only the release team ships
The right to promote belongs to a release team defined for the project, while other developers deploy to test as often as they like. If that rule is ever removed, the pipeline refuses the release, so permissions never widen quietly.
One move back from a bad release
A crashing pod, a missing image or broken configuration counts as a failure straight away. The previous image and configuration are restored together and production is checked for service again, so a half-finished rollback never happens.
Patches arrive without code changes
Every week a patched operating system layer is slid under all images without touching the application layer. No rebuild, pull request or developer time is needed, and image bases stay current while the team works on features.
Builds without a Dockerfile
The pipeline recognises the language and framework from the files in your repository and builds the image from source itself, so no Dockerfile is required. For special needs you can still build from your own Dockerfile, with the base image taken from the platform registry.
Your application in one file
Name, port, size, health check, environment variables and dependencies are written in one short file. You never write a Kubernetes manifest; the pipeline generates manifests from that file with mandatory rules such as resource limits and disruption budgets.
A database in one line
Add a database dependency to the application file and you get a single copy in test and a redundant three-copy database in production. The connection address reaches the container as an environment variable, with nothing extra to order or wire up.
A build environment for every project
Each project builds on its own runner, in its own namespace. A project's build can write only to its own image area, and a tool installed or a file left behind for one client project never carries over into another's build.
Scanned images that never run as root
Images produced by the pipeline are scanned for vulnerabilities in Nesnet's private registry, stored with a software bill of materials (SBOM) and run as a non-root user. An image from outside the platform registry, or one that runs as root, is not admitted to the cluster.
Dependencies that update themselves
An update bot opens pull requests when it finds newer chart, image and workflow versions. Patch and minor updates merge automatically, major changes wait for a person, and every version change shows up in commit history.
Secrets even developers never see
Passwords and API keys never sit in the repository as plain text; they are kept encrypted or in a separate secret store. The application file names the secret only, and its value reaches the container at run time without ever entering git history.
Your own domain with automatic HTTPS
Point your own domain at the application with a CNAME record, and its TLS certificate is issued automatically and renewed before it expires. Nobody needs a calendar reminder or a manual upload to keep it valid.
Applications talk only to whom they may
Declare in the application file which applications may call yours and which ones it calls. The pipeline turns that declaration into network and access policy, and hands over the called application's address as an environment variable.
Single sign-on in front of your app
An application opened to internal users can optionally sit behind corporate authentication. Users sign in with their Identity and SSO account, so you never write a login screen of your own.
A release record nobody can erase
Every release is written to an append-only record per project: what shipped, when, and whether it was rolled back. In an audit or an incident review you never go looking for production history in a separate system.
Release and roll back from the console
In the web console you promote a release, return to the previous one, and manage secrets, add-ons, domains and backups. Team members who avoid the command line work under the same rules and the same permissions.
Deploy through your AI agent
Your coding agent connects to the pipeline over its MCP interface and does what a developer does, through the same GitOps paths. The agent cannot write to the cluster directly; it leaves every change as a commit under the release team's rule.
Why Nesnet
Production never gets a rebuild
Promotion is not a build step: the image tried in test is copied byte for byte into the production area and the digest of the copy is verified. The second build behind most "it worked in test" surprises simply does not exist here.
In daily production on platforms Nesnet runs
This pipeline is used in production every day on customer platforms that Nesnet builds and operates. It was installed while live products on those platforms kept running, and yours comes with the same components and the same rules.
Only GitOps writes to the cluster
The GitOps tool is the only thing that deploys; no other tool or person writes to the cluster directly. Even the platform's own automation cannot change production, because every change arrives as a commit.
No inbound connections
No webhook from the internet is opened into the cluster for deployments; the pipeline polls for changes from the inside. No shared secret is kept in your repository either, so there is no key to leak.
Your code and images stay in Türkiye
Builds run on Nesnet's runners, images live in Nesnet's private registry and applications run on clusters in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. Your built software never passes through a build service abroad.
One monthly e-Invoice
The pipeline and the cluster resources it runs on arrive on one monthly invoice, as an e-Invoice. Chasing the payments of a foreign build service billed per minute leaves your finance team's agenda.
Example scenarios
A product team moves from manual deploys to commits
Situation
A product team ships new releases by connecting to a server and copying files. Nobody records who changed what, and finding the last working state after a failure takes hours.
Outcome
Developers push and the change appears in test, while the release team promotes to production. A bad release brings back the previous image and configuration together, and every step sits in git history.
A release that works in test and breaks in production
Situation
A software team runs a separate build for production. A bug that never showed in test appears only in production, because the two environments are not running the same image.
Outcome
On the pipeline, the production image is a digest-verified copy of the test image. The only difference between environments is configuration, and that is visible in git.
A software firm running projects for several clients
Situation
A software firm develops separate projects for different clients. On a shared build server, a tool installed for one project can break another project's build.
Outcome
Each project builds on its own runner in its own namespace and can write only to its own image area. Opening a project for a new client comes down to one registration step.
Images that keep failing the scan
Situation
Dozens of a company's services share the same old operating system base, and the scan report grows longer every month. Nobody has time to rebuild each service by hand.
Outcome
The weekly refresh slides a patched base under every image while the application layer stays the same. The report shrinks, and developers write not a single line of code for it.
An organisation preparing for an audit
Situation
An organisation's internal audit asks which changes reached production in the last six months and who approved them. Because deployments were manual, the answer is pieced together from emails.
Outcome
On the pipeline every release goes into an append-only record and every change into a commit. The auditor sees the release record and git history, and who approved is read from the release team list.
Who does what
| Nesnet | You |
|---|---|
| Installs and runs the runners, the private registry and GitOps delivery. | You write your code and tests and push to your GitHub repository. |
| Operates the rules for promotion by digest, digest verification and joint rollback. | You decide who sits on the release team. |
| Refreshes the operating system layer beneath your images every week. | Your release team decides which version ships to production and when. |
| Gives every project its own runner, namespace, quota and network policy. | You approve major-version dependency updates. |
| Issues domain certificates and renews them before they expire. | You define dependencies, secret names and access permissions in your application file. |
Who it is for
Software teams with no operations staff
Software teams with no operations staff and no plans to hire them. A developer who has never used Kubernetes pushes code, and the application is running in test within minutes.
Teams that control who ships
Teams that want everyone to deploy to test but only the release team to promote to production. The permission lives on one list rather than in every tool.
Multi-project software firms
Software firms running several client projects at once. Each project builds on its own runner in its own namespace, and no project can touch another's build.
Teams deploying by hand
Teams that ship today by copying files to a server or running kubectl by hand. Because every change is a commit, the audit trail builds itself.
Organisations facing audits
Organisations that must show in writing who promoted what to production, and when. Every release lands in an append-only record, and every production change has a commit behind it.
May not be the right fit
Teams that keep source code outside GitHub and do not plan to move it, since the pipeline builds with GitHub workflows. Managed Kubernetes fits better there: deploy from your own build tooling using the cluster's kubeconfig.
Developers who want to publish a single web app without release teams or separate environments. Nesly Serverless Platform fits better there, as the self-service counterpart of the same push-to-live workflow.
Under the hood
Builds and tests run from your GitHub Actions workflows. The runners that execute them live inside a Kubernetes cluster on Nesnet, one set per project. Built images are pushed to Nesnet's own image registry and scanned for vulnerabilities. A GitOps controller is the only component that deploys to the clusters: the desired state lives in git and the cluster is brought into line with it. Updates for charts, images and Actions arrive as proposed pull requests, and certificates for your domains are issued and renewed automatically. On top of these tools Nesnet adds its own rules: production is promoted by digest copy and verified, only an authorised release team can ship, a failed release rolls back image and configuration together, and the operating system layer is refreshed every week. The pipeline runs on Managed Kubernetes clusters in the Nesnet cloud.
Building blocks
- GitHub Actions workflows
- runs your builds and tests; the workflow file stays in your repository
- Per-project runners
- run your workflows inside the cluster, separately for each project
- Private registry and vulnerability scanning
- images stay at Nesnet, are scanned, and public registries are cached
- GitOps controller
- the only component that writes to the cluster; desired state in git
- Automated update proposals
- pull requests for chart, image and Actions versions
- Automatic certificate management
- domain certificates issued and renewed before they expire
- Managed Kubernetes
- the clusters the pipeline deploys to
How it compares
| Option | When it is the right choice |
|---|---|
| Your own build tooling plus Managed Kubernetes | The right choice if your team already has a settled pipeline on GitLab CI, Jenkins or another tool and does not want to replace it. Take the cluster as Managed Kubernetes and deploy from your own pipeline with the kubeconfig. |
| Building the pipeline with your own platform team | Makes sense if you want to tune every component yourself and have a platform team that will keep these tools running for years. Every component here is open source; what Nesnet adds is the rules and the operation. |
| Nesly Serverless Platform | Lighter for single-app projects that need no release team or separate environments. A push to the connected branch goes straight live, and accounts are self-service. |
Technical specifications
| Build and test | GitHub workflows |
|---|---|
| Runners | In-cluster, one per project |
| Image registry | Private registry, vulnerability scanning, cache for public registries |
| Delivery method | GitOps; only the delivery tool writes to the cluster |
|---|---|
| Target clusters | Kubernetes clusters on the Nesnet cloud |
| Deploy to test | On every git push |
| Promotion | Digest copy of the tested image, digest verified |
|---|---|
| Who can ship | The project's release team only |
| Rollback | Image and configuration together, then a health check |
| Operating system layer | Refreshed weekly, without a rebuild |
|---|---|
| Dependency updates | Patch and minor automatic, major approved |
| Certificates | Issued and renewed automatically |
| Secrets | Encrypted in git or held in a separate secret store |
| Data centres | Equinix Istanbul (Dudullu), Türk Telekom Ankara; data stays in Türkiye |
|---|
If something breaks
If a release fails to come up in production
The pipeline treats it as a failure without waiting and restores the previous version's image and configuration together. The job is not considered done until production is confirmed to be serving again.
If the build or tests fail
The release is not promoted. The version currently in production keeps running as it is, and the fixed code goes through the pipeline again on the next push.
If the GitOps tool stops
Clusters keep running the applications they already have. The only effect is that new changes are not applied; when the tool runs again it catches up with the state in git.
If a public registry is unreachable
The public images your build needs come from the registry's cache. An outside registry's limit or outage does not cut a build short.
Frequently asked questions
Pricing and first steps
Pricing
The CI/CD Pipeline is billed monthly based on resource usage, with invoices issued as e-Invoices. The number of projects, the cluster resources your environments use and your build volume make up the bill, and the scope is worked out together at the quote stage.
What the price depends on
- Number of projects on the pipeline; each comes with its own runner
- Number of test and production environments and the node size of the clusters they run on
- Build volume, since runners use the cluster's vCPU and RAM
- Additional services your applications use, such as databases
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.Your repositories, environments and release team are worked out in one call, and a quote is prepared.
- 3.Your project is registered and your developers make the first push.
Put the image you tested into production
Tell Nesnet's team about your projects, environments and release process, and you will hear back within the same business day. After the first push your developers stop asking anyone to deploy, and only the releases you approve reach production.