# 😇 Hi, Welcome to our Blog
Source: https://blog.clouddley.com/index

Learn more about Clouddley, who we are, what we do, and why it matters.

<b>🛠 Who We Are:</b>

We are a passionate team of remote engineers based across the globe building the next-gen Cloud platform. Our goal is to take a hard look at the existing state of infrastructure and build a system to enable better developer access with little or no Infrastructure overhead.

<b>✏️ What You Can Expect:</b>

Here, you will find in-depth articles, announcements, and engineering posts about what we have built and/or going to build.  Our aim is to create a resourceful and enlightening space for all of our readers.

<b>🌟 Join Our Community:</b>

Whether you’re an experienced engineer, a student, or simply someone interested in learning more about the world of Clouddley, there is something here for everyone. We encourage you to follow us on social media( [X](https://x.com/ClouddleyHQ) , [LinkedIn](https://www.linkedin.com/company/clouddley/) ) and join our [community](https://github.com/clouddley/community) for any issues you may have. Head over to [Github Discussions](https://github.com/clouddley/community/discussions)

<b>🚀 Let’s Get Started:</b>

We are excited to have you here and can't wait to embark on this journey of exploration and discovery together. Start by checking out our latest posts and [documentation](https://docs.clouddley.com/), or explore our different categories to find topics that interest you the most.

Thank you for being here, and once again.

Cheers to engineering the future together.


# Clouddley v2 - What's coming?
Source: https://blog.clouddley.com/posts/clouddley-v2-what's-coming



Hey there,

Today, we are launching Clouddley v2, and all the new features we will release are thrilling. Before diving in, let’s talk about Clouddley.

**Clouddley** is a backend Infrastructure platform for your compute, focusing on applications, services, databases, and AI workloads. We will focus on releasing offerings to help developers, founders, startups, etc., move fast with little to no Infrastructure overhead.

## What’s new in v2

We’re thrilled to unveil Clouddley v2, with revamped UI/UX, improved workflows and expanded support for deploying on your infrastructure quickly.

### Dashboard

We’ve rebuilt the dashboard from the ground up to make navigation smoother, surface real-time logs and metrics more transparently, and simplify key tabs such as Custom Domains, Logs and Deployments. Feedback from you over the past couple of months drove these changes.

<Frame>
  <img />
</Frame>

Here’s a glimpse of how app deployments look on Clouddley.

<Frame>
  <img />
</Frame>

Get real-time visibility into your builds and app activity with detailed logs.

<Frame>
  <img />
</Frame>

Track performance and resource usage effortlessly with Clouddley’s built-in metrics on the dashboard.

<Frame>
  <img />
</Frame>

### Teams

You will be able to create and manage team members.

<Frame>
  <img />
</Frame>

Collaborate effortlessly by adding team members and managing projects together on Clouddley.

<Frame>
  <img />
</Frame>

### Documentation & Blog

Thanks to [Bọ́lájí Ayọ̀dejì](https://x.com/iambolajiayo) and [Faith Kovi](https://www.linkedin.com/in/faith-kovi/), we’ve successfully migrated our [documentation](https://docs.clouddley.com/) from **Docusaurus** to **GitBook**, and our [blog](https://blog.clouddley.com/) now runs on **Mintlify**. While Docusaurus is an excellent open-source tool, it didn’t give us the flexibility and speed we needed as we scaled. **GitBook** now provides a cleaner interface, improved search, and an easier way to organise and update content. Our **Mintlify** blog, on the other hand, provides a faster writing and publishing workflow with built-in formatting and improved SEO visibility, allowing us to share product updates, tutorials, and technical stories more easily. We’re still improving, so your feedback means a lot.

### Customer Support Upgrade

We want to take care of our customers. We strongly believe there is no business without customers. We have updated all paying plans to include **Chat and Email Support**. As long as you are a paying customer, you will be taken care of as soon as we get your complaints or issues.

## Product Offering (Apps, Databases, Servers):

We are super excited about what we are building because we want to finally give folks who use virtual machines and bare metal servers more power. [You can try Clouddley free for 30 days — no credit card required.](https://app.clouddley.com/auth/signup) Clouddley comes with some exciting features. Here’s a snapshot of what you can do on Clouddley now:

* Deploy [apps](https://docs.clouddley.com/apps) via Git integration (GitHub & Bitbucket supported) — automatic detection of runtime (e.g., [Express.js](https://docs.clouddley.com/apps/how-to-guides/deploy-an-express.js-application-on-clouddley), [Next.js](https://docs.clouddley.com/apps/how-to-guides/deploy-a-next.js-app-on-clouddley), [Go](https://docs.clouddley.com/apps/how-to-guides/deploy-a-go-application-on-clouddley), [Python](https://docs.clouddley.com/apps/how-to-guides/deploy-a-fastapi-app-on-clouddley) ) and auto-deploy. You can also deploy using a [Dockerfile](https://docs.clouddley.com/apps/extras/deploy-an-application-with-a-dockerfile-on-clouddley). Deployments comes with features like unlimited deployments, [automatic rollback, manual rollback,](https://docs.clouddley.com/apps/extras/how-to-rollback-an-application) [pause/resume applications,](https://docs.clouddley.com/apps/extras/how-to-pause-and-resume-applications) and [environment-variables](https://docs.clouddley.com/apps/extras/environment-variables) runtime support—notifications via Email; build-time and runtime environment variables.

* Support for deploying and managing [databases](https://docs.clouddley.com/databases) ([PostgreSQL](https://docs.clouddley.com/databases/how-to-guides/deploy-a-postgresql-database-on-clouddley.), [MySQL](https://docs.clouddley.com/databases/how-to-guides/deploy-a-mysql-database-on-clouddley), [MariaDB](https://docs.clouddley.com/databases/how-to-guides/deploy-a-mariadb-database-on-clouddley), [Valkey](https://docs.clouddley.com/databases/how-to-guides/deploy-a-redis-database-on-clouddley) ) on your compute instances.

* [Servers](https://docs.clouddley.com/servers) – Manage virtual machines across multiple OS options like Ubuntu, Debian, and Fedora from any cloud provider.

## Pricing

Find the right [pricing plan](https://clouddley.com/pricing) for your team, whether you’re experimenting, scaling, or running production workloads.

* **Starter:** \$10/month — great for side-projects and testing. Includes app deployment, databases, brokers, Kubernetes clusters, background jobs, and GitHub deploys.

* **Pro (Recommended):** \$25/month — adds open-source LLM model deployment (coming soon), service metrics, custom domains, and DDoS mitigation.

* **Business:** \$100/month — built for production teams. Includes everything in Pro plus AI insights into pipelines, model fine-tuning (coming soon), higher service limits, and priority support.

<Note>You can start with any plan on a free trial and upgrade later.</Note>

## ​Clouddley v2.5 - What's coming?

We have an exciting new product offerings coming to Clouddley in version 2.5 - **Brokers and Build Packs Support.**

### Brokers

Brokers will simplify the management of real-time communication between your services. You’ll be able to deploy and manage message brokers like **RabbitMQ** and **NATS** on a server directly from the Clouddley dashboard.
Whether you’re running background jobs, building event-driven systems, or streaming data, **Brokers** will handle the provisioning, scaling, and monitoring for you automatically. It’s a simple, reliable way to connect your services and keep your applications running smoothly.

### Build Packs Support

We will make deployments even smoother with support for [Nixpacks](https://nixpacks.com/docs) and [Railpacks](https://railpack.com/).
If you’ve ever wished for a faster, more predictable build process, this one’s for you. **Nixpacks** automatically detects your app’s language and dependencies, then builds lightweight, reproducible environments — no Dockerfile needed. It’s perfect for developers who want speed and simplicity.
**Railpacks**, on the other hand, make builds faster and smaller by leveraging BuildKit, and support Node, Python, Go, and PHP out of the box. It is optimised for performance and flexibility.
They give you more control over your build configurations while keeping setup time low. Together with Dockerfile support, these new build options let you choose what works best for your workflow — whether you’re shipping a simple web app or scaling a complex microservice.

## Conclusion

These new builders give you more options, improved performance, and a smoother experience overall. We can’t wait to see what you build next.

*From all of us,*\
*The Clouddley Team.*

<div>
  <img alt="Faith Kovi" />

  <div>
    <div>
      <p>
        <span>By</span>

        <a href="https://x.com/Vera__Kaka">
          <span>Faith Kovi</span>
        </a>
      </p>

      <button>
        <Icon icon="share-nodes" />
      </button>

      <button>
        <Tooltip>
          <Icon icon="clone" />
        </Tooltip>
      </button>
    </div>
  </div>
</div>


# How We Cut Our Google Cloud Bill by 60% with Clouddley
Source: https://blog.clouddley.com/posts/how-we-cut-our-cloud-bill-by-60-percent-with-clouddley



When we first launched, we went all in on Google Cloud’s managed services — Cloud Run, Cloud SQL, Memorystore, Cloud Tasks, and Cloud Monitoring.

It felt like magic at first.

But soon, that magic came with a hefty bill: **\$4,000+ per month** mostly from idle workloads, overprovisioned services, and pricing models optimised for Google's bottom line, not ours. Month after month, costs crept up.

So we asked a simple question:

> “What if we ran **everything** on VMs — but still on Google Cloud — and used Clouddley to automate it all?”

That’s when we made the call: shift workloads from managed PaaS to our own VMs. It wasn’t an overnight decision, and it wasn’t risk-free. But it paid off: We did it. We **cut our bill by over 60%.**

## What you’ll learn in this

* Why PaaS can become a financial trap at scale
* How we identified the workloads to move
* The cost breakdown before and after the migration
* The challenges we faced and how we solved them
* Lessons you can apply if you’re making a similar move

## The wake-up call

We hit the tipping point during a review. Our finance team noticed that most of our operating expenses were going into cloud services. For a company still chasing profitability, that was very unsustainable.\
Here’s what our original setup looked like:

| Component            | Service on Google Cloud   | Monthly Cost |
| -------------------- | ------------------------- | ------------ |
| App Runtime          | Cloud Run                 | \$1,600      |
| Database (Postgres)  | Cloud SQL                 | \$1,200      |
| Redis Cache          | Memorystore               | \$322        |
| Background Workers   | Cloud Tasks               | \$400        |
| Logging & Monitoring | Cloud Ops Suite           | \$100        |
| Add-ons / Networking | Cloud NAT + Load Balancer | \$500        |
| **Total**            |                           | **\$4,122**  |

On paper, we were paying for lots of infrastructure. In reality, most of our workloads were **predictable and steady**, which meant we were paying a premium for features we rarely used.

## The turning point

Our CEO asked a simple question:

> “What would this cost if we just ran it on VMs?”
> I mean, we are building the next big thing for servers: **backend infrastructure for compute**. Why don’t we implement it internally?

We modelled the numbers. The same workloads, if sized correctly and run on dedicated VMs with automation in place. That meant potential savings in figures too big to ignore.
We migrated everything to **Google Compute Engine VMs**, but used **Clouddley** as our platform to manage:

* Provisioning
* Networking (DNS, TLS, Load Balancing)
* Observability (Logs, Metrics, Alerts)
* Backup & Failover
* Secrets & CI/CD

**The best part?**
Clouddley gives us all that **for free** — no markup, no monthly license, just full access to our own Google Cloud account.

## The migration journey

We didn’t jump in blindly. We built a migration plan in three phases:

**1. Audit and identify**\
We tagged and tracked workloads for 30 days. The result confirmed what we suspected:

* 70% of compute usage was flat and predictable.
* Less than 15% of workloads had spiky, unpredictable traffic.
* Databases were overprovisioned by at least 40%.

**2. Pilot migration**\
We started small, moving background workers and a staging environment to VMs. Within a month, we reduced the bill without service disruption. That gave us confidence to move production workloads, and we did.

**3. Full rollout**\
Over three months, we migrated:

* App servers → VM pool behind a managed load balancer.
* Redis cache → self-managed on VMs.
* Worker queues → smaller VM fleet that scaled with demand.

## The outcome

Now this is what the new setup looks like

**New Setup (Fully on VMs)**

| Component             | Monthly Cost |
| --------------------- | ------------ |
| App servers (GCE)x2VM | \$650        |
| PostgreSQL DB (GCE)   | \$700        |
| Redis (GCE)           | \$250        |
| Workers (GCE)         | \$200        |
| Monitoring & Logs     | Free         |
| **Total**             | **\$1,800**  |

## The results

* **60%+ cost reduction**
* More **predictable performance** (no cold starts, full CPU control)
* **Full visibility** into workloads, disk, memory, and traffic
* No vendor lock-in — all infra runs in our own Google Cloud project
* Ability to scale compute up or down as needed — no PaaS limits

## The bigger picture

Cutting 60% from our cloud bill wasn’t just about saving money. It gave us:

* **Financial headroom** to invest in new product features.
* **Operational control** to fine-tune workloads for performance.
* **Strategic flexibility** to mix PaaS and VMs instead of being locked in.

The cloud is about choice. Sometimes that means choosing convenience, other times it means choosing control. For us, making that choice, workload by workload, unlocked massive savings and made our business more resilient.

<Card title="Getting started with Clouddley?" icon="user-plus" href="https://app.clouddley.com/auth/signup">
  A backend infrastructure for your own compute. Run apps, databases, brokers, and AI workloads on your VMs, bare metal, or VPS.
</Card>

<div>
  <img alt="Faith Kovi" />

  <div>
    <div>
      <p>
        <span>By</span>

        <a href="https://x.com/Vera__Kaka">
          <span>Faith Kovi</span>
        </a>
      </p>

      <button>
        <Icon icon="share-nodes" />
      </button>

      <button>
        <Tooltip>
          <Icon icon="clone" />
        </Tooltip>
      </button>
    </div>
  </div>
</div>


# Run apps, databases, brokers, and AI anywhere - with no vendor lock-in
Source: https://blog.clouddley.com/posts/run-apps-databases-brokers-and-ai-anywhere-with-no-vendor-lock-in



Every developer knows the trade-off.

You’ve built something exciting, and now it’s time to deploy. The options? Either you go with a managed platform that feels smooth at first but quickly piles on costs and locks you in. Or you self-host, where you get complete control along with endless configuration files, monitoring headaches, and the constant fear that one missed update will take everything down.

It’s a choice between speed and freedom. And for too long, that’s just been the way things are.

At Clouddley, we asked a simple question: *why can’t you have both?*

## A better way to run workloads

Clouddley was designed for developers who want *simplicity* and *ownership*. We call it **backend infrastructure for your compute**. That means you get the power to run apps, databases, brokers, and AI workloads anywhere without tying yourself to a single vendor.

Here’s what that looks like in practice:

* Deploy on your own servers, VMs, or bare metal.
* Run across AWS, GCP, Azure, Hetzner, Scaleway, DigitalOcean, wherever your project needs to go.
* Enjoy simplicity with instant deploys, quick rollbacks, and effortless scaling.

You stay in control. We remove the friction.

## Why it matters

It really comes down to three significant advantages:

* **Lower costs.** Running the same workloads on your own servers or a cloud service is often a fraction of the price of managed platforms.

* **Real freedom.** Move across providers and regions without starting from scratch or worrying about vendor restrictions.

* **More creativity.** Instead of spending hours fussing over YAML files or juggling cloud dashboards, you focus on what you actually want to build.

Developers don’t get into this field to struggle with infrastructure. They do it to solve problems, create new ideas, and ship faster. Clouddley makes space for that.

## A real-world example

Take a startup building an AI-driven customer support tool. At first, they deployed on a managed PaaS. It was fast and easy until their customer base grew. Suddenly, scaling costs tripled, and moving workloads across regions became a nightmare. The more they built, the more they felt trapped.

With Clouddley, the same team can deploy AI workloads, such as running open-source LLMs across AWS EC2 instances for their U.S. customers, run databases on a more affordable provider like Hetzner in Europe, and still maintain the simplicity of instant deploys and rollbacks. They get the freedom to run where it makes sense without rewriting their entire stack or losing valuable time.

That’s the difference. Infrastructure should empower growth, not hinder it.

## The shift that’s already happening

Infrastructure is changing. More teams are realising they don’t have to pick between two extremes. The future isn’t about choosing which vendor you’ll commit to for the next five years. It’s about choosing yourself, owning your workloads, your costs, and your freedom.

Clouddley is here to help make that shift possible.

## Choose yourself

With Clouddley, you don’t compromise. You run apps, databases, brokers, and AI workloads anywhere with simplicity, control, and no lock-in.

The next generation of infrastructure isn’t vendor-led. It’s developer-led.\
And that starts with you.

<Card title="Getting started with Clouddley?" icon="user-plus" href="https://app.clouddley.com/auth/signup">
  A backend infrastructure for your own compute. Run apps, databases, brokers, and AI workloads on your VMs, bare metal, or VPS.
</Card>

<div>
  <img alt="Faith Kovi" />

  <div>
    <div>
      <p>
        <span>By</span>

        <a href="https://x.com/Vera__Kaka">
          <span>Faith Kovi</span>
        </a>
      </p>

      <button>
        <Icon icon="share-nodes" />
      </button>

      <button>
        <Tooltip>
          <Icon icon="clone" />
        </Tooltip>
      </button>
    </div>
  </div>
</div>


# Introduction
Source: https://blog.clouddley.com/tutorials/introduction

Welcome to the official Clouddley Tutorials hub!

Whether you're just getting started or looking to deepen your expertise, you're in the right place. Here, you'll find clear, step-by-step tutorials to walk you through **deploying apps**, **setting up databases**, **configuring brokers**, **adding servers**, and more on Clouddley.

<img alt="Clouddley Logo" />

<img alt="Clouddley Logo" />

## Why Clouddley?

Clouddley makes deploying and managing applications on your preferred cloud provider easy with our <b>Bring Your Own Cloud (BYOC) model</b>. Built with security and simplicity, our platform offers a unified experience for deploying apps, managing infrastructure, and scaling confidently. We focus on removing the complexity, so you can focus on building great products.

## What You’ll Learn

We’ve designed these tutorials to make your journey with Clouddley as smooth as possible. You’ll find in-depth instructions on:

* <b>Apps</b> – Learn how to build, deploy, and manage your applications easily on Clouddley.
* <b>Databases</b> – Set up and easily maintain your databases.
* <b>Brokers</b> – Configure and manage messaging brokers for efficient communication between services.
* <b>Servers</b> – Add and manage servers to support your applications.


# Quickstart
Source: https://blog.clouddley.com/tutorials/quickstart

Get the guides you need to deploy, run, and scale on Clouddley fast and with your favorite cloud providers.

## Before You Begin

**What you need:**

* An active Clouddley account
* Basic knowledge of your chosen technology stack
* Familiarity with the command line interface (CLI) of the cloud provider of your choice

## Featured Tutorials

[How to Build a Weather Alert MCP Server in Python and Deploy it with Clouddley →](/tutorials/how-to-build-a-weather-alert-mcp-server-in-python-and-deploy-it-with-clouddley)

[Deploy a Ruby on Rails app on a DigitalOcean Droplet using Clouddley →](/tutorials/how-to-deploy-a-ruby-on-rails-app-on-a-digitalocean-droplet-using-clouddley)

[Deploy MySQL Database on a Scaleway Instance using Clouddley →](/tutorials/how-to-deploy-a-mysql-database-on-a-scaleway-instance-using-clouddley)

[Deploy a MongoDB Database on a DigitalOcean Droplet using Clouddley →](/tutorials/how-to-deploy-a-mongodb-database-on-a-digitalocean-droplet-using-clouddley)

[Deploy a NestJS app on a Scaleway Instance using Clouddley →](/tutorials/how-to-deploy-a-nestjs-app-on-a-scaleway-instance-using-clouddley)


# null
Source: https://blog.clouddley.com/tutorials/tags/aws



<div>
  <h1>
    AWS
  </h1>

  <p>
    Explore expert tutorials, guides, and resources on <strong>aws</strong>.
    This tag includes everything from best practices to deep-dives.
  </p>
</div>

***

<CardGroup>
  <Card title="Deploy a Golang Application on an AWS EC2 Instance using Clouddley" href="/tutorials/how-to-deploy-a-golang-application-on-an-aws-ec2-instance-using-clouddley" icon="book-open">
    <br />

    <p>August 21, 2025</p>
  </Card>

  <Card title="Deploy a FastAPI Application on an AWS EC2 Instance using Clouddley" href="/tutorials/how-to-deploy-a-fastapi-application-on-an-aws-ec2-instance-using-clouddley" icon="book-open">
    <br />

    <p>August 29, 2025</p>
  </Card>

  <Card title="Deploy a PostgreSQL Database on an AWS EC2 Instance using Clouddley" href="/tutorials/how-to-deploy-a-postgresql-database-on-an-aws-ec2-instance-using-clouddley" icon="book-open">
    <br />

    <p>September 10, 2025</p>
  </Card>

  <Card title="Deploy a MongoDB Database on an AWS EC2 Instance using Clouddley" href="/tutorials/how-to-deploy-a-mongodb-database-on-an-aws-ec2-instance-using-clouddley" icon="book-open">
    <br />

    <p>September 13, 2025</p>
  </Card>
</CardGroup>


# null
Source: https://blog.clouddley.com/tutorials/tags/digitalocean



<div>
  <h1>
    DigitalOcean
  </h1>

  <p>
    Explore expert tutorials, guides, and resources on <strong>DigitalOcean</strong>.
    This tag includes everything from best practices to deep-dives.
  </p>
</div>

***

<CardGroup>
  <Card title="Deploy a Ruby on Rails app on a DigitalOcean Droplet using Clouddley" href="/tutorials/how-to-deploy-a-ruby-on-rails-app-on-a-digitalocean-droplet-using-clouddley" icon="book-open">
    <br />

    <p>June 16, 2025</p>
  </Card>

  <Card title="Deploy a Flask app on a DigitalOcean Droplet using Clouddley" href="/tutorials/how-to-deploy-a-flask-app-on-a-digitalocean-droplet-using-clouddley" icon="book-open">
    <br />

    <p>May 20, 2025</p>
  </Card>

  <Card title="Deploy a MongoDB Database on a DigitalOcean Droplet using Clouddley" href="/tutorials/how-to-deploy-a-mongodb-database-on-a-digitalocean-droplet-using-clouddley" icon="book-open">
    <br />

    <p>July 08, 2025</p>
  </Card>

  <Card title="Deploy a MariaDB Database on a DigitalOcean Droplet using Clouddley" href="/tutorials/how-to-deploy-a-mariadb-database-on-a-digitalocean-droplet-using-clouddley" icon="book-open">
    <br />

    <p>July 14, 2025</p>
  </Card>
</CardGroup>


# null
Source: https://blog.clouddley.com/tutorials/tags/scaleway



<div>
  <h1>
    Scaleway
  </h1>

  <p>
    Explore expert tutorials, guides, and resources on <strong>Scaleway</strong>.
    This tag includes everything from best practices to deep-dives.
  </p>
</div>

***

<CardGroup>
  <Card title="Deploy a NestJS app on a Scaleway Instance using Clouddley" href="/tutorials/how-to-deploy-a-nestjs-app-on-a-scaleway-instance-using-clouddley" icon="book-open">
    <br />

    <p>June 09, 2025</p>
  </Card>

  <Card title="Deploy a .NET Core app on a Scaleway Instance using Clouddley" href="/tutorials/how-to-deploy-a-dotnet-core-app-on-a-scaleway-instance-using-clouddley" icon="book-open">
    <br />

    <p>July 01, 2025</p>
  </Card>

  <Card title="Deploy a MySQL Database on a Scaleway Instance using Clouddley" href="/tutorials/how-to-deploy-a-mysql-database-on-a-scaleway-instance-using-clouddley" icon="book-open">
    <br />

    <p>July 17, 2025</p>
  </Card>

  <Card title="Deploy a Valkey Database on a Scaleway Instance using Clouddley" href="/tutorials/how-to-deploy-a-valkey-database-on-a-scaleway-instance-using-clouddley" icon="book-open">
    <br />

    <p>August 26, 2025</p>
  </Card>
</CardGroup>