Important Update:
Less than 10 minutes after this response went live, Nigel, Developer Advocate at Cloudsmith and the author of the original article, deleted his entire Medium account.
No clarification. No defense. Just gone.
I think that says everything you need to know, about the credibility of the original post, and about the standards Nigel and Cloudsmith are willing to stand behind when challenged with facts.
Why This Blog Exists?
Anyone can share their opinion, and that’s a beautiful thing, until someone with limited knowledge and a loud microphone 🎤 starts spreading false information with a commercial goal in mind.
That’s exactly what happened in this blog post by Nigel Douglas, who works for Cloudsmith (more on that later…). His article attempts to argue that JFrog Cloud isn’t truly cloud native.
Before we move on, Nigel, please don’t insult your readers.
When you say things like “I stumbled upon the Cloudsmith platform” or “According to Cloudsmith’s website, they offer…” come on, man… they literally pay your salary, the same as JFrog pays mine. Tell that upfront to readers!
I see you’ve only been in the role for two months, so let me offer a word of advice:
This community values transparency and honesty.
We developers can smell a sales pitch or misinformation from 100 miles away, so tread carefully.
The problem? Your blog is riddled with technical inaccuracies, flawed assumptions, and a shallow understanding of what cloud-native architecture actually means.
I’m not here to play personal games. I’m here to protect the integrity of our industry and ensure developers aren’t misled by amateur-level analysis dressed up as an expert opinion.
Section 1: The Claim — “JFrog Cloud runs on VMs, not containers. It’s lift-and-shift.”
What Nigel says:
“JFrog Cloud tends to run on traditional infrastructure like Virtual Machines (VMs) instead of containers. While containerised workloads aren’t the only basis for ensuring a web app is cloud-native, you can often tell in the cloud version of JFrog that it’s a lift-and-shift.”
The reality:
This is either pure speculation or an outright fabrication.
Because the truth is simple:
- JFrog Cloud has run on containers since October 2018
- It has been deployed on Kubernetes since the same date, and is one of the first companies to adopt Kubernetes in production
- It uses KEDA (Kubernetes Event-Driven Autoscaling) for dynamic, Resource-efficient scaling. It was designed from day one for high-scale, cloud-native workloads
So when you throw around “lift-and-shift,” what you are really exposing is this:
You didn’t do the homework.
Not even basic validation. Not even a glance at public talks, docs, or architecture discussions. This is not an opinion, this is an observable fact:
- JFrog Helm charts
- JFrog on Kubernetes
- Internal scaling using KEDA, Helm, and Prometheus event triggers (used across environments)
This is not a VM-first platform retrofitted to survive in the cloud.
JFrog is a container-first, Kubernetes-native, horizontal-scaling SaaS built to power some of the world’s most demanding software supply chain pipelines.
Psssst, it was all there. Just waiting for you to read it 😉
Section 2: The Claim — “You still need to manage infrastructure”
What Nigel says:
“Even in managed cloud versions, it often requires more manual setup, scaling considerations, and maintenance than a truly cloud-native service.”
The reality:
- Completely FALSE for JFrog Cloud SaaS.
- JFrog customers do not manage nodes, clusters, upgrades, or scaling.
- He confused on-prem/self-hosted setups with SaaS — a rookie mistake.
- JFrog Cloud SaaS is fully modular, horizontally scalable, and Kubernetes-native
Yes, JFrog started as a monolithic app, like literally every major platform that was created before 2010, but today JFrog containerized services, with clear separation of responsibility and scaling logic per component
So yes, the product evolved. Because that’s what great engineering teams do: they constantly innovate and scale architecture to meet ever-changing demands. That’s not a weakness. That’s maturity.
Here are some references for you:
Section 3: The Claim — “Stateful = not cloud native”
What Nigel says:
“JFrog’s design heavily depends on persistent storage and state, which isn’t inherently bad, but it’s less cloud-native than services built for ephemeral, stateless scaling”
The reality:
- This is either a misunderstanding of basic cloud-native architecture or a complete disconnect from reality
- Stateful stores like PostgreSQL and of course bucket-based artifact storage are standard and mandatory in cloud-native platforms.
- Cloud-native is about how services are designed and managed, not whether they persist data.
References:
- CNCF Cloud Native Definition: cloudnative.dev
- Cloud-native stateful services: Stateful Workloads on Kubernetes
Section 4: The Claim — “JFrog isn’t SaaS or multi-tenant”
What Nigel says:
“JFrog offers Artifactory and other tools in the cloud, and it’s also hosted on AWS, Azure, and GCP. So yes, it’s cloud-hosted, but as stated earlier that doesn’t automatically make it cloud-native.”
The reality:
- JFrog Cloud is a fully managed, multi-tenant SaaS running across AWS, GCP, and Azure.
- Customers can choose between multi-tenant, isolated-tenant, or hybrid options.
- There is zero need for customers to manage or maintain infrastructure.
References:
Press enter or click to view image in full size
Final Thoughts: Why This Matters
This blog isn’t about hurt feelings. It’s about integrity in technical discourse.
When someone publishes a post with such low technical rigor and high confidence, it doesn’t just reflect poorly on them — it pollutes the technical conversation.
And when that person represents a competitor, it raises a real question:
Is this ignorance, or intentional misinformation?
To Nigel:
You had the right to publish your thoughts, but responsibility comes with that privilege.
Next time, do more than skim a few terms. Ask someone who’s built in the cloud. Read the documentation. Learn.
When you mix immaturity with a lack of technical depth and give it a platform, you create noise, not value.
This kind of behavior damages trust in our industry and makes it harder for engineers to make the right decisions.
Nigel, next time, please do your research.
Expertise takes time. Stability. Focus. Stay humble
Press enter or click to view image in full size