Envirobly has been my three-year obsession: a control plane that wires into your AWS account to run services, databases and gateways with zero-downtime deploys and live observability. I launched it in October 2025 after iterating relentlessly—and then realized the story was only half told.

This post documents what shipped along the way and why I’m pivoting toward an open source, bare metal and VPS friendly future.

2022 – First AWS experiments

• October 2022: rails new, AWS SDK wiring and CloudFormation EventBridge ingestion so stacks/resources could be mirrored in the app.
• Users, projects, resources, and dashboards established the “account → project → stack” model with a UI for streaming stack events.
• Stack templates, sample event ingestion, and automatic region discovery created a thin but working AWS control plane by November.

2023 – From stacks to services

• Services and environs arrived with domains, shared instances, autoscaling containers, CloudWatch logging, build log streaming and an auto-deploy-from-branch UI (May 2023).
• Deployments matured: completed builds fed deployments (July 2023); long-running workflows gained a custom stepped-action engine with checksum + concurrency controls (December 2023).
• Config delivery moved to S3 and instance metadata, keeping hosts immutable while letting services update quickly.

Early 2024 – Data durability and foundations

• Universal AMIs for builders/runners (January 2024).
• OpenZFS-backed data volumes with backup/restore and host orchestration for service EBS backups made persistent workloads first-class.
• Service data-volume mounts, backup scheduling, and stepped “trash” flows reduced risk when deleting or rolling back services.

Spring 2024 – Observability and networking polish

• Prometheus metrics for services/gateways plus Traefik router metrics and edge log collection delivered unified dashboards.
• Networking hardened with ACME-issued vanity domains, DNS/SSL automation, and the ability to scale gateways to zero when idle.

Summer 2024 – Deployment pipeline hardening

• Zero-downtime improvements for deploys and an API/CLI-friendly deployment surface replaced earlier experiments.
• Config deployments covered all service attributes and a stepped post-deploy cleanup deleted build contexts to prevent cache drift.

Fall 2024 – CLI-first developer workflow

• UI-based service provisioning was removed in favor of pure config-backed configuration, powered by envirobly CLI.

2025 – Resilience, UX, launch

• Storage/backup track: OpenZFS 2.3.0, Docker registry cache (instead of snapshot-based build caching), striped ZFS volumes for maximum EBS IOPs and throughput, snapshot backups, and cross-region restores, plus a UI for scheduling backups and browsing deleted services.
• Developer workflow: git-object push/pull baked into envirobly-cli culminated in CLI v1.0.0, with UI deploy/exec snippets for copy/paste ease.
• Stripe billing, per-profile access tokens, and Turnstile-protected signups tightened edges.
• Launched to production in early October 2025 🎉🥳

Why pivot after launch

• Despite launch traffic, early interest relied on me constantly posting on X; it was exhausting and still yielded zero paying customers.
• Despite all the cost optimization, AWS is still about 10x more expensive compared to bare metal or VPS from vendors like Hetzner or OVH. Small to medium customers and solo developers are my main target audience. I didn’t want to face this discrepancy until I basically finished the product 🤪
• An open-source release, in theory, promises “passive” discovery via GitHub, backlinks and community contributions that marketing alone couldn’t sustain.
• Keeping the old product live would create false expectations, so I replaced it with a clear pivot notice and a waiting list.
• It’s early, there are no paying customers to disappoint. Better now then waiting and hoping for things to change.

The unexpected pivot: open source and bare metal

• Direction: shift Envirobly to an open source model optimized for bare metal and VPS deployments, while keeping a hosted “convenience” option from the original author. Hopefully this will help with building trust, squash any vendor lock-in fears and open the door for community contributions that can even make it into the SAAS version, ala Fizzy.
• Value prop: run on your own servers with live replication, so stateful apps can migrate quickly during failures or upgrades. “Your app, your servers, with a safety net.”
• Messaging: a concise landing update describing the pivot, a call to join the waiting list, and no lengthy feature promises until the new product is ready.
• License stance: MIT or O’Saasy. I’ll decide as I go along and things crystallize.
• Next steps: start the open source version, validate the bare metal/VPS workflows in public and relaunch with a single, focused story instead of maintaining the legacy AWS path I lost faith in.