In-House vs SaaS Platforms for Software Companies: Know Your Risk

Should a software company run its own platforms in-house or on-prem so it knows its risk? Partly. Self-hosting does not remove risk, it moves the risk onto your own team, so the right answer is decided platform by platform: own the systems that are critical, hard to replace or bound by regulation, rent the ones a specialist runs better than you would, and keep a tested exit plan for every one.

The evidence cuts both ways. Software-as-a-service (SaaS) failures hit many customers at once, as Atlassian's 14 day outage in 2022 and CircleCI's 2023 breach showed. Self-hosted software fails differently: in October 2023 CISA and the FBI warned that self-managed Confluence servers were being exploited, while Atlassian's cloud sites were not affected. Below: both sides, platform by platform, with a decision table, a risk register template and a phased plan.

Key takeaways

• "On-prem everything" trades concentration risk for patch latency, staffing and backup risk. Neither model is safe by default; knowing which risk you hold, and planning for it, is what makes you safe.
• SaaS failures are correlated. Atlassian's April 2022 outage locked 775 customers out for up to 14 days, and none could fix it themselves.
• Self-hosted failures are mostly patch failures. For GitLab's critical CVE-2023-7028 in January 2024, GitLab.com was already patched while every self-managed instance had to upgrade.
• GDPR, DORA and the Cyber Resilience Act do not say "self-host". They ask for processor contracts, lawful transfers, registers of providers, concentration assessments, tested exit plans and fast handling of exploited vulnerabilities.
• The strongest cases for owning a platform are build runners that hold signing keys, artifact mirrors, and, where contracts demand it, source control and AI inference. Identity is the hardest platform to self-host well.
• Every platform, rented or owned, needs an owner, a restore or export you have tested, and an exit plan written before you need it.

Is "own everything" the right instinct?

The instinct is sound. A software company that cannot say where its code lives, who can read its build logs or what happens if its chat tool vanishes for a week does not know its risk, and what you run, you can see.

But visibility is not safety. Self-hosting hands you every job the provider did: patching within hours of a critical advisory, backups you have restored, on-call at three in the morning, hardening, upgrades and end-of-life planning. Large providers staff each of those jobs. A 40 person company usually has one platform engineer who also owns the build pipeline.

So the useful version of the instinct is "know your risk for every platform", then pick the model with the lowest total risk you can carry. Sometimes that is on-prem. Often it is SaaS with a strong contract, a tested export and a second path for critical functions. For the same trade-off applied to scanners, see our honest comparison of self-hosted and SaaS security scanning.

What the deployment models actually mean

The words get used loosely, so pin them down before deciding anything.

Two points are easy to miss. Self-managing in your cloud account still leaves you exposed to the cloud provider: Slack traced its January 2021 outage to an overloaded cloud Transit Gateway. And air-gapped systems are the safest against remote attackers but the slowest to patch, because every update crosses the gap by hand.

What real incidents teach about both models

These cases come from the providers' own post-incident reports and CISA advisories, chosen to show both failure modes, not to single out any provider. Publishing a detailed account is itself a point in a provider's favour.

Lesson 1: SaaS risk is correlated risk

When a SaaS provider fails, every customer fails together and none of them can fix it. Atlassian's customers had safe data and still could not reach their tickets and wikis for up to two weeks. If your source control, CI/CD, ticketing and chat all depend on one provider, or on providers sharing one cloud region, one fault can stop your whole delivery pipeline. That is what regulators mean by concentration risk.

Lesson 2: a SaaS breach becomes your incident

CircleCI's root cause was ordinary: one laptop, one stolen session cookie, one employee able to generate production tokens. Customers then had to rotate every secret stored in the service. ED 24-02 had the same shape at larger scale. Anything you put into a SaaS platform has the provider's security posture as its ceiling; self-hosting changes whose posture that is, and only raises the ceiling if your team runs the system better.

Lesson 3: self-hosted risk is patch latency

In the Confluence and GitLab cases the vendor's cloud was unaffected or already fixed, and the exposure sat entirely with self-managed instances. A self-hosted platform is only as safe as the time between an advisory and your upgrade. ED 24-01 adds that for some appliances patching was not enough: CISA's required actions included vendor recovery steps and status reporting. Owning a system means owning its incident response.

Neither model wins all eight events. What you control under either model is the inventory, the tested backup and the written plan.

Platform by platform: what to own and what to rent

Source control

It holds your code, history and review records, the most valuable thing a software company owns. Self-hosting buys data location, network isolation and control of upgrade timing, and for export-controlled or defence work it can be the only option. It costs you an internet-facing server that holds every code credential and needs critical patches within days, as the GitLab case shows. Default: SaaS or dedicated SaaS with a nightly mirror to storage you control; self-manage only when contracts or regulation require it and you can staff the patching.

CI/CD and build runners

CI holds secrets, signing keys and the power to change what ships, which is why CircleCI's breach mattered so much to its customers. The most useful split in this guide is here: keep the CI control plane as SaaS and run ephemeral build runners on your own machines, so signing keys and deploy credentials stay inside your network. Many hosted CI products support self-hosted runners for this reason. Harden them so untrusted pull requests cannot reach them; our guide to securing self-hosted GitHub Actions runners covers the settings.

Artifact registries and package mirrors

An internal proxy in front of public registries gives you a stable, auditable copy of every dependency, keeps builds working when a public registry is slow or a package disappears, and gives you one place to control which versions may be used. The cost is storage and the duty to patch and lock down a server that every build trusts. For production builds this is one of the cheapest, highest-value pieces of self-hosting a software company can do.

Ticketing, wiki and chat

These hold plans, incident notes and, too often, pasted tokens and customer data. Self-hosting buys retention and location control but little availability, because you become the provider, and the Confluence case shows how attractive self-managed collaboration servers are to attackers. Default: SaaS with scheduled exports, a rule that secrets never go in tickets or chat, and an out-of-band incident channel that does not share your main chat tool or identity provider. Slack's January 2021 outage hit on the first Monday back after the holidays; a second channel is cheap insurance.

Identity and single sign-on

Identity holds the keys to everything else, and it is where a small team is least likely to match a specialist provider on patching, monitoring and abuse detection. CircleCI's incident shows that even strong SSO falls to a stolen session, so session lifetime, device binding and token scope matter more than where the identity provider runs. Default: SaaS identity with phishing-resistant authentication for administrators, short production sessions, offline break-glass accounts and a documented way in if the provider is down.

Observability

Logs can carry personal data and tokens. Whatever backend you use, run the collection and scrubbing layer yourself so personal data and secrets are removed before anything leaves your network.

AI models and coding assistants

Prompts carry source code, customer data and architecture. Local or private-cloud inference guarantees prompts stay in your environment, at the cost of GPU capacity, model updates and possibly lower capability on hard tasks. Decide per data class: hosted models under enterprise terms with clear retention for general work, local inference for code and data your contracts keep in-house.

Security tooling

Scanner results are a map of your weaknesses. Self-hosting keeps findings inside your environment and avoids giving a third party repository access, but you must keep vulnerability data current, which in air-gapped setups means a reliable offline update path. At minimum, prefer tools that can scan locally and send only results, and confirm what leaves your environment before connecting any repository.

Decision table: SaaS, dedicated, self-managed or on-prem

Use this as a first pass, then adjust with the risk register below.

Third-party and concentration risk

DORA, the EU's Digital Operational Resilience Act, gives the clearest legal definition. It describes ICT concentration risk as dependency on one or more closely related critical ICT providers such that their failure "may potentially endanger" critical or important functions. DORA binds EU financial entities, but the idea fits any software company: if one provider's bad day stops you shipping, you have concentration risk.

Article 29 offers two tests worth borrowing: is the provider easily substitutable, and do you already have several critical arrangements with the same or closely connected providers? It then asks firms to weigh alternatives. It does not say "bring it in-house"; recital 74 lists switching provider and moving to in-house solutions as equally valid exit routes.

Count dependencies, not vendors. Three SaaS tools in one cloud region, behind one identity provider, alerting through one chat tool, are one dependency in a bad week. NIST SP 800-161 Revision 1, published in May 2022, frames the root problem as decreased visibility into how acquired technology is built, integrated and run, and its practices apply to services as much as products. Our post on vendor concentration risk in the software supply chain goes deeper on scoring.

You can reduce concentration risk four ways, and only one is self-hosting:

1. Substitutability. Keep data exportable and test the export. A Git mirror is a working emergency substitute for source control.
2. Diverse dependencies. Keep the out-of-band incident channel off your main provider and identity system.
3. Contract terms. Data location, notice of subcontractor changes, data return on exit, audit rights and incident notification.
4. Selective self-hosting. Own the few components where an outage would stop you and no substitute exists, such as build runners and the artifact mirror.

Data sovereignty and regulation

Most pressure toward on-prem comes from regulation and customer contracts. Read from the official texts, none of the main EU laws requires self-hosting as such.

GDPR: processors, transfers and security

Article 28 lets a controller use only processors "providing sufficient guarantees" of appropriate measures, under a binding contract, and a processor may not add sub-processors without the controller's written authorisation. Every SaaS tool holding personal data is a processor. Article 44 allows transfers outside the EU only under Chapter V's conditions, and without an adequacy decision Article 46 requires appropriate safeguards plus enforceable rights and remedies. EU-region self-hosting avoids that question, though vendor support access from outside the EU can still be a transfer.

Article 32 asks for security appropriate to the risk, including the ability to restore availability and access to data in a timely manner, which is a restore requirement that applies equally to systems you run. Article 33 requires breach notification to the supervisory authority without undue delay and, where feasible, within 72 hours, and a processor must tell the controller without undue delay. A SaaS provider's breach notice can start your clock.

DORA: ICT third-party risk for financial entities and their suppliers

DORA has applied since 17 January 2025. Software companies feel it through contracts, because financial customers must flow it down:

• Register of information. Article 28(3) requires a register of all ICT service arrangements, marking those that support critical or important functions.
• Exit strategies. Article 28(8) requires exit strategies for critical services, so the entity can leave without disrupting the business, compliance or clients. Exit plans must be documented and tested.
• Contract content. Article 30(2) requires the locations where services run and data is processed and stored, with advance notice of changes, and access, recovery and return of data in an accessible format on insolvency or termination.

If you sell to EU banks, insurers or investment firms, expect questions about where your own platforms run and how you would exit them. See our post on DORA third-party ICT risk for financial services.

The EU Cyber Resilience Act: duties on what you ship

The CRA (Regulation (EU) 2024/2847) covers products with digital elements and their remote data processing solutions. Under Article 71 it applies from 11 December 2027, but the Article 14 reporting obligations for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026. Recital 12 places SaaS and other cloud services under the NIS2 Directive instead, unless the cloud part is remote data processing a manufacturer designed for its product. The CRA does not tell you where to run internal tools. It raises the value of knowing what is in the software you ship and fixing exploited flaws fast, which depends on your runners, artifact mirror and dependency inventory.

What "data sovereignty" means in practice

Ask customers which one they mean before re-architecting; many "on-prem" questionnaire answers are satisfied by residency plus contract terms.

What you take on when you self-host

Most "bring it in-house" plans underestimate this list. Price every line first.

The last two rows are where self-hosting quietly adds supply chain risk: a self-managed Git platform, wiki or registry is built from hundreds of open source components that you now pull, trust and update.

Step by step: run a self-hosted platform safely

Step 1: Inventory what you run and which versions

You cannot patch what you have not listed. On Kubernetes, list every Helm release and running image.

helm list -A

kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' | sort -u

For self-managed GitLab, check the version through the API or on the host.

curl -s -H "PRIVATE-TOKEN: $GITLAB_TOKEN" https://gitlab.example.internal/api/v4/version

sudo gitlab-rake gitlab:env:info

Step 2: Check your versions against known exploited vulnerabilities

Filter CISA's Known Exploited Vulnerabilities catalog for the products you self-host.

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[]
      | select(.vendorProject|test("GitLab|Atlassian|Jenkins";"i"))
      | [.dateAdded, .cveID, .product, .dueDate] | @tsv' \
  | sort -r | head -20

Anything in that list that matches a version you run is an emergency, not a backlog item.

Step 3: Pin images by digest and scan them

Tags move; digests do not. Pin images by digest, and scan both the images and the repository that deploys them.

docker buildx imagetools inspect registry.example.internal/platform/wiki:9.2.1 \
  --format '{{json .Manifest.Digest}}'

safeguard scan --image registry.example.internal/platform/wiki@sha256:<digest>
safeguard scan --dir ./platform-deploy

Results land as JSON under ./output, usable as evidence for an auditor or questionnaire.

Step 4: Take backups and prove the restore

Warning: restore commands overwrite data. Before running any restore, confirm the target host and instance with hostname and the platform's version check, and never restore onto production to "test" it.

sudo gitlab-backup create
sudo tar czf /secure/backups/gitlab-config-$(date +%F).tgz /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json

The backup archive leaves out gitlab.rb and gitlab-secrets.json, so the second line copies them. Restore into a separate test instance every quarter and record how long it took. That is your real recovery time.

Step 5: Keep a SaaS exit path warm

For platforms you keep as SaaS, the equivalent of a backup is a tested export. For source control, a mirror is simple.

git clone --mirror https://git.example-saas.com/acme/payments.git /srv/mirrors/payments.git

git -C /srv/mirrors/payments.git remote update --prune

Once a quarter, build a release from the mirror alone with public registries blocked.

Risk register template

One row per platform, reviewed quarterly and after any provider incident. The columns match what GDPR, DORA and customer questionnaires ask.

Score likelihood times impact and sort. A high-scoring row that supports a critical function and is not substitutable is your next project, whatever its deployment model.

A phased plan

1. Weeks 1 to 2, inventory. List every platform, its owner, where it runs, what data it holds and which critical function it supports. Fill in the risk register. Most teams find a platform with no owner and a critical function with no exit plan.
2. Weeks 3 to 6, contracts and exits. For each SaaS platform confirm processor terms, sub-processors, data location, breach notification and data return. Turn on exports and mirrors, and write one page per critical platform on how you would work for a week without it.
3. Weeks 6 to 10, identity, secrets and backups. Phishing-resistant admin authentication, shorter production sessions, long-lived secrets out of CI and chat, a first restore test of every self-hosted platform, and an out-of-band incident channel.
4. Quarter 2, selective in-sourcing. Bring in the components the register flags as critical and hard to substitute, usually build runners and the artifact mirror first. Move source control or AI inference only if regulation or contracts require it and you have staffed patching and on-call.
5. Ongoing. Quarterly restore tests, an annual exit drill for one SaaS platform, and a register review after any provider incident. Track patch latency for every self-hosted platform; it decides whether self-hosting made you safer.

Where Safeguard fits, honestly

Safeguard does not run your Git server, patch your wiki, back up your databases or replace your identity provider; those duties stay with you or your providers. It is relevant to the security tooling row of the decision table and the dependency and image inventory both models need.

For that row, Safeguard offers these options, all generally available (GA):

• Deployment models [GA]. Multi-region SaaS, private VPC or dedicated tenancy, full on-prem in your own datacenter, and fully air-gapped with the AI models running inside your environment and signed offline snapshot delivery. The platform is cloud-agnostic.
• AI modes per tenant [GA]. Full AI with Safeguard's own models; Zero AI, where the platform runs deterministically with no LLM in the loop; bring your own approved model; or quantized local and on-prem versions of Safeguard's models running inside your environment.
• Local runner [GA]. The CLI can run on your own macOS, Windows or Linux machine, pull the repository locally, scan there and send back only encrypted results, so source code does not leave your environment. A Kubernetes Helm operator supports self-hosted deployments.
• Network posture [GA]. Safeguard does not hold persistent or open connections; it polls. Customer code, SBOMs and telemetry are not used to train shared models.

Safeguard's SOC 2 Type II audit is underway, not complete.

Common mistakes

• Treating "on-prem" as a security control. It is a deployment model. Without patching, backups and monitoring it can be less safe than the SaaS it replaced.
• Counting vendors instead of dependencies. Five tools on one cloud region and one identity provider are one failure.
• Never testing the export. An export you have not restored is a hope, not a plan.
• Storing secrets in CI variables, chat and tickets. That turns a provider breach into your breach.
• Self-hosting identity to feel in control. Spend the effort on phishing-resistant admin authentication and short sessions instead.
• Forgetting the platform's own supply chain. Self-managed platforms ship as images and charts full of open source. Pin and scan them.
• Reading "sovereignty" as "air-gapped". Ask whether the customer means residency, sovereignty or isolation first.
• Writing the exit plan during the outage. DORA requires it in advance for critical services; everyone else should copy that.

FAQ

Is self-hosting more secure than SaaS?

Not automatically. It gives you control of data location, exposure and upgrade timing, but moves patching, backups and incident response onto your team. CISA's October 2023 Confluence advisory and GitLab's January 2024 critical release both hit self-managed instances while the vendors' cloud services were unaffected or already patched.

Should a software company host its own Git server?

Only if regulation, export controls or contracts require it and you can apply critical patches within days. For most teams, SaaS or dedicated SaaS with a nightly mirror you control gives most of the resilience for far less work.

What is concentration risk in software supply chains?

The risk that one provider's failure stops a critical function because you depend heavily on it, or on providers sharing its infrastructure. DORA asks EU financial entities to check whether a provider is easily substitutable before relying on it.

Does GDPR require data to be stored on-prem or in the EU?

No. It requires processor contracts with sufficient guarantees, a lawful mechanism for transfers outside the EU, security appropriate to the risk and breach notification within 72 hours where feasible. EU hosting can simplify transfers but is not mandatory.

What does DORA require from software vendors?

DORA binds EU financial entities, not most vendors directly. But those entities must register ICT providers, assess concentration, keep tested exit strategies and include terms such as data location and data return, so vendors should expect those clauses.

Does the EU Cyber Resilience Act apply to SaaS?

Generally no. Its recitals place SaaS under the NIS2 Directive unless the cloud part is remote data processing designed for a manufacturer's product. The CRA applies from 11 December 2027, with reporting duties in force since 11 September 2026.

Should we self-host our CI/CD build runners?

For jobs that sign, deploy or touch production, usually yes. A SaaS control plane with ephemeral runners on your own infrastructure keeps signing keys and deploy credentials in your network. Keep untrusted pull requests away from them.

Should we run AI coding models on-prem?

Decide by data class. Where contracts keep code or data in-house, use local or private-cloud inference. Elsewhere, hosted models under enterprise terms with clear retention may be more capable and cheaper to run.

What should a SaaS exit plan include?

The data you need, its export format, where it goes, who runs the export, how long it takes, which functions stop and for how long, and when you last tested it.

How often should we test restores of self-hosted platforms?

At least quarterly for anything supporting a critical function, and after every major upgrade. Restore into a separate instance and record the time as your real recovery time.

Fix it without waiting for upstream

Whichever model you choose, your platforms and your products are built from open source: the Git server, wiki and registry you self-host ship as container images full of third-party components, and so does the software you sell. Self-hosting makes the patch timing for those components your problem, so closing the gap between a published fix and a running fix matters even more on-prem.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos shows a platform migration or a risk register. They show Safeguard's tooling running in the shapes this guide discusses, with code on your machines and a person approving each action. To try the CLI, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is the "scan locally, send only results" pattern from the security tooling row of the decision table.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. Asked to fix the lodash CVE in a repo, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The same flow works on the deployment repository of a self-hosted platform, and you decide what gets pushed.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Choosing tools per assistant is the least-privilege habit this guide recommends for every platform.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• EUR-Lex: Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA)
• EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation (GDPR)
• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act (CRA)
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• CISA AA23-289A: Threat Actors Exploit Atlassian Confluence CVE-2023-22515 for Initial Access to Networks
• CISA Emergency Directive 24-01
• CISA Emergency Directive 24-02
• GitLab: Critical Security Release 16.7.2, 16.6.4, 16.5.6
• Atlassian: Post-incident review on the April 2022 outage
• CircleCI: CircleCI incident report for January 4, 2023 security incident
• Slack Engineering: Slack's outage on January 4th 2021
• GitHub: October 21 post-incident analysis

Last reviewed: 23 October 2026. Regulatory dates and provider terms change; check the linked texts and reports for the latest wording.