dotCloud
dotCloud was a developer platform-as-a-service that helped teams deploy and host applications without directly managing servers.
View original storyProduct snapshot
What it was
dotCloud helped developers deploy, host, assemble, and run applications on a managed platform.
Who it was for
Problem / value
Reduced low-level infrastructure work for application teams.
Core workflow
- deploy web applications
- host app components
- avoid managing low-level server infrastructure
Core dependency
Customers depended on the hosted platform, support, uptime, and migration path, not only on the underlying container technology.
Product form
Pricing model
Commercial PaaS pricing existed historically, but public shutdown sources do not disclose active pricing or revenue at shutdown.
What happened
Summary
The dotCloud PaaS business was sold away from Docker and later shut down after cloudControl insolvency.
Outcome
The original hosted PaaS ended, while Docker became the more important product direction.
Demand signal
The public record shows that Docker became the valuable strategic focus while the original dotCloud hosted PaaS was sold and later shut down after cloudControl insolvency. The lesson is about business-model fit, not technical quality.
Distribution issue
Developer PaaS was a crowded and operationally heavy market. The platform also created customer migration risk because users depended on the hosted service staying alive.
Timeline
- dotCloud existed before Docker became the company focus
- dotCloud, Inc. became Docker, Inc.
- PaaS business sold to cloudControl in 2014
- Service shutdown announced for February 29, 2016
Before you build
Why it matters
Developer infrastructure products carry uptime, support, migration, pricing, and competitive obligations that can outgrow the original product thesis.
Primary check
Separate the hosted-service business from the underlying technical primitive: prove customers will pay for the operated platform, not just admire the tool it creates.
Checklist
- Interview paying users separately about the hosted workflow and the underlying technology.
- Model support and uptime costs before expanding the service.
- Create a migration plan before onboarding production workloads.
- Do customers pay for the operated platform or mainly want the underlying tool?
- What are the support, uptime, and migration obligations per customer?
- Could the internal primitive become the clearer product?
Relevant if
- You are building a developer platform, hosting tool, deployment service, or infrastructure wrapper.
- Your most valuable asset may be an internal tool rather than the hosted product customers first see.
Less relevant if
- You are building a single-player developer utility with no hosted operations or customer migration risk.
Pre-build tests
- Sell a narrow hosted workflow to a few production users and track support load.
- Release or demo the primitive separately to test whether it pulls stronger demand than the platform.
Transferable lessons
- Validate the service business separately from the underlying technology.
- Model support, uptime, migration, and shutdown obligations before selling infrastructure.
- Watch for a platform shift that makes the internal tool the real product.
If you build this today
Validate the hosted service and the primitive separately. Measure paying customers, uptime/support burden, migration liability, and whether the underlying tool deserves to become the product instead.