Source control, CI/CD, boards, environments, testing, logs and observability, behind single sign-on with MFA and VPN. On infrastructure we operate, in locations you choose.
A person exists once on the platform. Their group membership decides what they can reach across source control, pipelines, registry, boards, logs and monitoring.
Adding someone to a team grants their access across the platform. Removing them withdraws it. The joiner case is easy. The other two are where the problems happen.
Sign-in, access and change events from across the platform are collected in one place, in one format.
Choose this model when your organisation needs these four things together, under one operating model that we run.
Source code, artefacts, container images, pipeline logs, ticket contents and secrets live in Zurich, Frankfurt, Istanbul, or your own data centre.
One identity per person, with MFA, reached over VPN. One place to look for sign-in, access and change events.
Build agents run inside your boundary. A build can reach an internal database, package mirror or licence server without you opening inbound access to it.
Maintenance, including upgrades and patching. Security, capacity, backup, monitoring and 24/7 response. Your engineers use the platform. They do not maintain it.
If your current platform already meets your requirements for location, access and operation, staying there may be the better choice.
Tell us what your team uses now for source control, CI, registry, boards, logging and monitoring. Tell us how access is managed today, and what has gone wrong recently.
You get an assessment of what consolidating would involve. Where the migration is straightforward, where it is awkward, and what it changes about your access and audit position.
One question is worth asking whatever you decide. Who backs up your hosted repositories, and when did you last test a restore?
We reply within 2 business days.
One identity per person, used by every component. Where you already run a corporate identity provider, we federate to it.
The platform is reached over VPN and is not exposed to the public internet.
Full history, branch protection, review requirements and merge policy configured to how your team works.
Build and deployment pipelines, defined as code in the repository, with build agents inside your boundary.
Private registry for images and packages, with retention policies set deliberately.
Boards and issues linked to the commits and pipeline runs that implemented them.
Development, staging, test and production, provisioned the same way, with a defined promotion path.
Application and infrastructure logs in one searchable place, with retention and access set per source.
Infrastructure, platform and application metrics, correlated with deployments.
Run by the pipeline across development, staging and test. Described below.
Full code history, plus virtual machine backups of the environments and the platform.
Performance tests run as part of the pipeline across development, staging and test. They track application metrics, latency, network, load and response times.
A baseline is captured for each service, so slower is a comparison and not an impression. The trend is visible over time, because a series of small regressions is harder to notice than one bad commit.
You set the thresholds per service. A failing threshold can stop the pipeline where you want it to, or report where you do not.
We publish no latency or throughput figures for this platform. What it measures is your application, against your baseline, on your thresholds.
Application and infrastructure logs are shipped to one searchable place. Retention is set per source. Access is controlled by role, because logs can contain more than intended.
Alerting reaches a person. Alerts are tuned deliberately, because an alert that fires often and means nothing trains a team to ignore alerts.
Repositories are backed up with their history and metadata. Artefacts are retained per policy. Virtual machine backups cover the environments and the platform. Backups are verified by restoring them into a real environment, on an agreed schedule.
Your repositories, artefacts, logs and tickets live in the locations you choose. That is written into the agreement.
Our team does not read your source code, your ticket contents or your application logs. Our responsibility is the platform they live on.
Administrative access is granted to named individuals, with least-privilege roles, MFA over a controlled path, and per-action logging. Where your obligations require access from a named jurisdiction, that is designed in and written into the contract.
That is the access model for this service. Where a customer asks us to operate an application as well, the access model is different. It is written into that agreement.
Migrations differ. These are the stages we plan against, and the order matters most at the beginning.
What exists, what is used, and what is still switched on. Repositories, pipelines and their dependencies, build agents, secrets and registries. Environments, identities, access lists, integrations and boards.
Centralised identity, MFA, VPN and group structure go in before anything else. Migrating repositories before identity migrates the access problem with them.
Migrated with full history, tags and branches. Both remotes can exist during the transition. Developers change one remote URL.
Images and packages moved, retention policies set, and the pull paths in your deployments updated.
Ported, then run in parallel with the existing ones on the same commits, until the outputs match. It is where undocumented steps, hand-built agents and credentials in unexpected places are found.
Targets configured, promotion paths set, approvals defined, and the first deployments run to a non-production environment.
Active and recent work is migrated in detail. Older items are migrated as a searchable record. Custom fields, comment formatting and workflow states may not map one to one. The old system stays read-only for an agreed period.
Log shipping configured, dashboards and alerting built, and baselines captured once the environments are stable.
Both systems run in parallel for an agreed period. The old platform goes read-only, then it is shut down on an agreed date, with the old subscriptions cancelled.
A senior engineer replies within 2 business days. If your current platform already meets your requirements for location, access and operation, you will hear that first.
