---
title: About Blossom
url: "/docs/intro/about/"
canonical_url: https://docs.blossom88.com/docs/intro/about/
markdown_url: https://docs.blossom88.com/docs/intro/about.md
summary: The people and experience behind Blossom
categories:
- introduction
- about
- story
---

# About Blossom

## Built From A Decade Of Deployment Work

[Blossom](https://app.blossom88.com) was built by [Tung
Nguyen](https://github.com/tongueroo), an engineer who spent a decade building
deployment tools across cloud platforms.

The tools came one at a time:

- **[Jets](https://rubyonjets.com)** — serverless Ruby on AWS Lambda
- **[UFO](https://ufoships.com)** — container deployment for AWS ECS
- **[Kubes](https://kubes.guru)** — Kubernetes deployment tool
- **[Terraspace](https://terraspace.cloud)** — Terraform framework
- And [others](https://boltops.com) across the DevOps landscape

Each tool made one part of application delivery easier. Each solved a real
problem and revealed the same pattern: deployment was not one command or one
tool away from being solved. It required a platform that stayed responsible
after the first deployment completed.

Blossom is that platform. It remembers the requested Product state, observes the
result, and safely works to keep the two aligned. It does not deploy an App and
walk away.

## How That Experience Shaped Blossom

The lessons became Product rules:

- Start with Apps, Environments, Services, Jobs, and Data
- Preserve desired state so work and recovery can continue after an
  interruption
- Check health before completing a Release
- Show Capacity and cost where the change is made, within one capacity limit
- Put logs, metrics, health, and Activity on the Product they explain
- Keep the App workflow consistent across Blossom Cloud and Blossom BYOC (bring your own cloud)

These rules make reliability visible through behavior and evidence rather than
through a list of implementation components.

## Track Record

Tung Nguyen is a **Former AWS Container Hero**, one of the first five
recognized worldwide.

The tools above are used by thousands of developers. Through running [BoltOps](https://boltops.com), a DevOps software consultancy, he has worked with teams across AWS, GCP, and Azure — seeing firsthand what works and what fails at different scales.

Blossom is not a first project. It is the platform that a decade of production experience pointed toward.

## One Product Across Clouds

Blossom Cloud provides the direct path: choose a Blossom region and deploy within
your capacity limit. Blossom BYOC connects a supported cloud provider account when
direct billing or an existing provider relationship matters.

Both use the same Apps, Releases, Capacity, observation, and recovery workflow.
The provider choice changes setup and billing responsibilities, not the Product
teams use each day. See [Cloud Providers](/docs/locations/cloud-providers/) for current
connection requirements.

## Trade-offs

Blossom is designed for production applications that need safe Releases,
scaling, recovery, and operational clarity without requiring teams to operate a
general-purpose orchestrator.

Teams with specialized scheduling or platform-engineering requirements may
still prefer Kubernetes or another lower-level system. Blossom deliberately
optimizes for the App workflow instead.

---

**Connect**: [GitHub](https://github.com/tongueroo) • [Blog](https://blog.boltops.com) • [X](https://x.com/tongueroo)