How Salesforce, GitLab, and Atlassian Do On-Prem — and Why Our Model Is Different
Seven enterprise tools compared on their on-prem deployment models. What each *assumes*, who each *excludes*, and why CollabOps started from a *different assumption*.
A common opening line in customer meetings: "Do you deploy like GitLab Self-managed?"
Answer: no. Why is the content of this post. We break down seven enterprise tools' on-prem models, then look at what each assumes.
Seven-tool comparison
Tool | On-prem model | Min requirement | Assumption | Customers excluded
───────────────────────────┼─────────────────────────────┼──────────────────────────────┼────────────────────────────────┼───────────────────────
Salesforce | Hyperforce (SaaS in effect) | (none — SaaS) | All data can live in cloud | 90% of KR public/finance
GitLab Self-managed | docker-compose / Helm | 4 vCPU (5 users) → 50+ k8s | Past 50 users, k8s available | Mid-size, no-k8s shops
GitLab Dedicated | AWS-managed onprem-like | (managed) | AWS usage acceptable | Air-gapped, non-AWS
Atlassian Data Center | k8s + external DB | k8s + Postgres + LB | Infra expertise present | Ops teams under 5 people
GitHub Enterprise (GHES) | VMware OVA | 4 vCPU + VMware/AWS | VMware or cloud | KVM, Hyper-V, OpenShift
Jenkins (LTS) | Self-managed jar | Java + DB | Self-operated | No DevOps headcount
Sentry self-hosted | docker-compose | Docker host | Not recommended for production (per docs) | Production usage
CollabOps | 5-class taxonomy (single VM · Helm · OVA · Operator · tarball) | 1 VM + 8 vCPU | No assumption of infra expertise | (deliberately almost none)The implicit message of each minimum
A tool's minimum requirement isn't a technical spec. It's a customer-segment selection.
Salesforce's message
"We do SaaS only. If you need on-prem, look elsewhere." Hyperforce runs on hyperscalers in customer regions, but not in customer-owned datacenters.
Markets excluded — Korean public agencies, the financial sector (especially K-ISMS-bound), Japanese government, parts of EU regulation. Tens of billions of dollars of market deliberately excluded. That is Salesforce's strategy.
GitLab's message
"Under 50 users, run on 4 vCPU. Past 50, adopt k8s." This message excludes the market that is under 50 users + has no plans to adopt k8s. That is the core market of Korean and Japanese regional banks and insurers.
Atlassian's message
"You have an infra-capable IT team." k8s + external DB + LB + shared file system = expertise across four areas. For a 5-person IT shop, four areas is too much.
GHES's message
"VMware or AWS/GCP/Azure." No k8s — paradoxically, GHES does not install on k8s. Customers on KVM, Hyper-V, or OpenShift need separate wrapping.
CollabOps's different assumption
The six tools above all match their respective ICPs. CollabOps targets a different ICP with a different assumption:
Assumption | Result
──────────────────────────────────────────────────────────┼────────────────────────────
No assumption of customer infra expertise | Five environment classes supported
Don't block customer's *next* decision | Embedded lightweight k8s → migration path to existing k8s
Don't infringe customer's data boundary | Air-gapped supported as default
SaaS is the *option*; self-hosted is the *default* | → /blog/product/why-self-hosted-defaultThese four assumptions align every deploy artifact decision. Change one assumption, the whole stack takes a different shape.
Who should pick which tool
Objectively:
Condition | Recommendation
───────────────────────────────────────────────────┼─────────────────────────
All data in cloud OK + standard ICP | Salesforce / SaaS DevOps
50+ users + k8s ops team | GitLab / Atlassian
VMware standard + some cloud OK | GHES / GitLab Dedicated
Public sector / finance / defense + air-gapped or in-house | CollabOps
≤5 infra people + own datacenter | CollabOpsThis isn't sales material. It's a decision matrix. CollabOps isn't the answer for every environment — our space is the environments other tools can't enter.
The real conclusion of seven comparisons
Each tool's minimum requirements reveal its origin.
- Salesforce — cloud-first origin → on-prem options retrofitted → effectively SaaS
- GitLab — open-source self-host origin → past 50 users assumed out of scope → k8s recommended
- Atlassian — infra-heavy enterprise origin → expert team assumed
- GHES — VMware-compatibility origin → weak in non-VMware environments
- CollabOps — Korean / Japanese public-sector and finance origin → any environment assumed
Tool selection isn't technical comparison. It's a comparison of whose environment each tool assumes.
If you're an IT decision-maker comparing DevOps on-prem tools, the minimum requirements alone across the five tools above show why some don't fit your environment. The most-frequent wrong call — picking a tool that works on 4 vCPU now but forces k8s adoption six months later. That's failing to price the six-months-later migration cost into today's decision.
Related posts
What Should a 100 Million Won Software Contract Change for the Customer?
The contract size a vendor wants and the reason a customer pays are two separate explanations. Working through a hypothetical ROI calculation to the end shows why counting only the hours saved per deployment falls short, and which items belong in the same table.
John Baek
The Customer Said They Hate Jira. Do They Need a New Jira?
Complaints about a familiar tool are easy to hear. But a complaint is not the same as a buying problem. What one conversation taught me about separating the friction a customer mentions from the problem their organization actually has to solve, and the four questions to ask instead.
John Baek
More Features, and a Harder Question: Why Us?
Issues, repositories, reviews, CI/CD, docs, AI. Every new feature made the product description longer, but not the reason to choose it today. So we changed the question: what decision can the customer not make right now? Why Change sits at the center of CollabOps.
John Baek