Forem: Defang.io

A Different Way to Think About Deploying Containers to the Cloud

Defang.io — Fri, 07 Nov 2025 17:28:01 +0000

This X thread begins with a big win:

You dockerized your entire app. Your Node API, your React frontend, your Postgres DB all neatly packaged. Your docker-compose file brings it all up perfectly on your machine. You feel like a genius.

Then it talks about how reality hits when it’s time to run the same stack in production. Suddenly you need reliability, and scaling across multiple machines. You start asking questions you never considered during local development. Questions about service discovery, resilience, rolling updates, and all kinds of other stuff. So... what is the proposed solution?

Kubernetes

The post proposes Kubernetes as a solution to all these problems when deploying containers. For those of you who don’t spend your time in the devops trenches, here’s a quick breakdown of what Kubernetes (often referred to as k8s) is and what it does. K8s is referred to as an orchestrator: it takes care of scheduling containers across many different machines in different configurations, moving them around when necessary, and making sure they’re running properly. It helps handle things like horizontal scaling, making sure containers have adequate resources, handling networking, and more.

To get to a working deployment of the proposed app, though, you would probably need to learn at least a dozen different k8s concepts. Here’s a short list of what you might need: a Deployment to describe Pods in a ReplicaSet along with a Service, Ingress and Ingress Controller to hook up your domain. Helm to install Cert Manager so you can get SSL working. You’ll likely need to learn about plenty more along the way.

Something you’ll noticed in the original post is that the author doesn’t mention the Postgres service from his app. That’s because in the majority of cases, it’s best to use the managed data stores offered by the cloud provider.

One last note about Kubernetes is that despite it feeling like “standard” tooling that lays on top of cloud infrastructure, you have to keep in mind that each k8s distribution has quirks. So some thing in EKS might not work the same way in GKE, AKS, or DOKS. That means it’s not going to be your silver bullet to writing once and then deploying to different cloud accounts (i.e. if you need to deploy to your customers’ accounts).

A Different Approach: Defang

One of the key things to keep in mind about Kubernetes is that a lot of k8s concepts map onto underlying cloud infrastructure. For example, creating a Service in your k8s cluster may provision a load balancer in your cloud (outside your cluster). It’s not a 1-to-1 relationship, but it’s often necessary to understand. The real point is that it’s hugely complex, and to do it properly, you have to learn essentially as much as if you did a full cloud certification.

At Defang, our approach to the original post’s problem is different. Docker Compose is more of a logical description of your application, expressing relationships between services, what’s exposed, etc. Our tool takes a standard Docker Compose file and turns it into cloud‑native infrastructure on AWS or GCP based on some parameters. So when you’re ready to deploy, instead of typing your usual docker compose up, you can type defang compose up and be up and running in the cloud in minutes.

That command provisions the necessary compute resources, networking, load balancers, and more directly in your cloud account. It will also provision managed data stores using your cloud’s managed services, including Postgres, Redis, and MongoDB. The Defang CLI will also help you manage encrypted configuration like API keys properly.

Extras for AI Developers

Beyond all that, our tooling comes with features that machine‑learning and AI developers might appreciate. For example, it offers easy integration with AWS Bedrock and Google Vertex AI, streamlining workflows that rely on those services.

Conclusion

In the end, Kubernetes has its place. It provides powerful primitives and is the right choice for certain types of organizations and workloads. It’s particularly useful when you need to orchestrate complex distributed systems that need special permissions or require an understanding of the specific compute environment, etc.

However, if your application can be accurately described by a Docker Compose file and is architected according to 12 Factor principles, a Compose file is likely sufficient. In those cases, using Defang is likely the easiest way to get a secure, scalable deployment without investing in a full Kubernetes setup. If you’re feeling overwhelmed by the never ending flexibility and complexity of k8s when you’re deploying containers, Defang might be worth checking out.

FastAPI deployment Heroku vs AWS / GCP with Defang

Defang.io — Thu, 23 Oct 2025 17:12:21 +0000

FastAPI is getting more and more popular, as is building agents. Developers building agentic systems are starting to turn to FastAPI as one of the more ergonomic web frameworks for building endpoints and then adding on a Model Context Protocol (MCP) layer so that AI agents can discover and invoke those endpoints as “tools”. For example, with FastAPI-MCP you can take an existing FastAPI application, attach mcp = FastApiMCP(app) and mcp.mount(), and your endpoints become usable by an LLM-based agent with minimal extra work.

But when it comes time to deploy your agent, how should you go about it?

TL;DR: Heroku is great to start, but you pay for convenience with higher tiers, less control, and platform lock‑in. Defang keeps the Heroku‑like workflow but deploys your FastAPI app into your own AWS or GCP account — you keep ownership, pay for cloud resources plus a Defang subscription, and ship with a single command.

What “shipping FastAPI” looks like on Heroku

A common Heroku setup runs FastAPI with Gunicorn and Uvicorn workers via a Procfile, plus requirements.txt. A typical entry is:

web: gunicorn -k uvicorn.workers.UvicornWorker main:app

This pattern is popular because it uses Uvicorn as an ASGI worker under Gunicorn. It’s easy to get running, but your region choices and infrastructure are limited by the Heroku platform.

What “shipping FastAPI” looks like on AWS/GCP with Defang

Defang reads your Docker Compose file to describe the app, then deploys it to your own AWS or GCP account with one command. You define your services once and deploy them the same way each time, but you own the account and have direct control over networking and managed services.

Try it locally with:

docker compose up

Then deploy to your cloud:

defang --provider=aws compose upor

defang --provider=gcp compose up

Defang transforms Compose files into cloud resources (compute, networking, TLS, storage) and wires managed Postgres/Redis when needed.

Why choose AWS/GCP + Defang over Heroku for FastAPI

Ownership & control

Heroku abstracts infrastructure. Defang deploys into your cloud account. You choose regions, networking, and compliance boundaries. Heroku does allow a region choice at app creation, but options are much more limited.

Cost basis

With Defang you pay for AWS/GCP resources plus a Defang subscription (e.g., $10–$30/user/month). You avoid Heroku’s dyno pricing. For comparison, a Standard‑1X dyno on Heroku costs $25/month, and Performance‑M costs $250/month. Data services are add‑ons (an Essential‑0 Postgres instance is ~$5/month). Heroku’s pricing is easy to understand but can be expensive at larger scales. Defang uses your cloud provider’s pay‑as‑you‑go model and supports cost‑saving deployment modes.

Portability and lock‑in

Heroku workflows can bind you to dynos and their add‑on ecosystem, making migration more involved. Defang uses standard containers and cloud services, so your Compose definition is portable across supported providers. Leaving Defang still requires replacing the automation we provide, but the configuration remains in Compose and everything is built with standard primitives from your chosen cloud.

Developer experience

Heroku’s appeal is its deploy experience: commit, push, and it’s live. Defang preserves that simplicity with a Compose‑driven workflow and a one‑command deploy. Updating your app triggers a diff and apply, rather than a fresh manual setup each time.

Head‑to‑head considerations

Where it runs: Heroku deploys your app on its own platform in a region you choose at creation. Defang deploys it in your AWS or GCP account, so you control networks, VPCs, policies, etc.
Deploy flow: Heroku uses a Procfile and recommends servers like Gunicorn or Uvicorn. Defang uses your Compose file and runs defang compose up to provision services.
Databases & caching: Heroku allows you to attach add‑ons for Postgres or Redis. Defang provisions managed Postgres (AWS RDS or GCP Cloud SQL) and Redis (Elasticache or Memorystore) directly in your account.
Costs at scale: Heroku pricing is tiered by dyno size; high performance dynos can reach $250–$1,500/month. Defang charges a subscription and then you pay AWS/GCP usage, which is often lower than Heroku, especially with Spot or smaller instances.
Lock‑in: Heroku’s dynos and add‑ons tie you to its platform. Defang uses open formats and cloud primitives, making migration easier if you decide to run infrastructure yourself later.

Migrating a FastAPI app: Heroku → AWS/GCP

Defang’s migration flow inspects your Heroku app, generates a Compose file, provisions equivalents like Postgres/Redis on your cloud, then deploys with one command. In practice, this means:

Analyze dynos, environment variables and add‑ons on your Heroku app.
Generate a Compose definition that mirrors your services.
Build & Deploy the app on AWS or GCP with a single defang compose up.

No code rewrite is required.

Minimal snippets

Heroku (Procfile)

web: gunicorn -k uvicorn.workers.UvicornWorker main:app

Heroku Dev Center recommends using a production server such as Gunicorn or Uvicorn. FastAPI typically runs with Uvicorn workers.

Defang (Compose File + CLI Commands)

compose.yaml

    services:  
      app:  
        build:  
          context: .  
          dockerfile: Dockerfile  
        ports:  
          - "8000:8000"

Then deploy with

    # Try locally  
    docker compose up  

    # Deploy to your cloud  
    defang --provider=aws compose up  
    # or  
    defang --provider=gcp compose up

Defang reads your Compose file and deploys, provisioning compute, networking and managed databases.

When to pick which

Heroku is ideal for quick prototypes or side projects where you accept platform limits and want an easy dyno-based deployment that you do not expect to scale much.
AWS/GCP + Defang makes sense once costs, control and ownership matter: especially for production FastAPI apps that need specific regions, VPC configurations or compliance requirements.

Try it yourself

You can see Defang in action with a one‑click FastAPI deployment. In a few minutes you’ll have FastAPI running in your own AWS or GCP account using the Heroku‑style workflow, no custom infra scripts required.

👉 Deploy FastAPI on Defang in one click

FAQ

Is Defang more complex than Heroku? No. Defang is designed to feel like Heroku: simple CLI deploys, but under the hood it translates a Compose file into cloud resources. You get a similar workflow with more control. Currently we generate one for you, but we’re also working on completely removing the Compose file requirement where possible.

Can I migrate an existing Heroku FastAPI app without rewriting it? Yes. Defang analyzes your dynos, add‑ons and env vars, generates a Compose file, and provisions the equivalent services automatically.

What about databases like Postgres or caching with Redis? On Heroku these are add‑ons. With Defang they are provisioned directly in your AWS/GCP account, using RDS/Cloud SQL for Postgres and Elasticache/Memorystore for Redis, so your data stays in your environment.

How does pricing compare? Heroku charges a monthly or hourly fee per dyno and add‑on (e.g., $25/month for a Standard‑1X dyno). Defang charges a small subscription fee, and you pay the underlying cloud costs directly to your cloud provider.

Why not just write Terraform or Kubernetes myself? You can, but that takes time and expertise. Defang provides a “define once → deploy anywhere” workflow; you can extend infrastructure later if you need more customization.

Deploy n8n to Your Cloud in Minutes with Defang

Defang.io — Thu, 16 Oct 2025 17:59:47 +0000

In early October 2025 n8n announced a huge US$180 million Series C funding round. Investors including Accel and NVentures valued the open‑source automation platform at US$2.5 billion. The reason is clear: n8n isn’t just a Zapier clone; it has evolved into a platform for AI orchestration. According to n8n’s founder, the current AI landscape oscillates between fully autonomous models and rigid rule‑based routing. n8n strives to strike a balance by giving builders control over “how much autonomy to grant” and building in orchestration and coordination so humans and agents work together. Flexible deployment is part of that promise: teams can self‑host n8n on their own infrastructure to keep data private and to integrate sensitive systems while using external data and third-party services as well.

Yet self‑hosting n8n isn’t trivial. A typical production setup involves configuring PostgreSQL, handling SSL certificates, tuning databases and scaling containers. Guidance from production‑grade self‑hosting guides point out that you have to handle all kinds of configuration across your database and services, and failures can lead to data loss or outages. For teams without a dedicated DevOps engineer this can be a deal‑breaker. That’s where Defang comes in. Defang wraps your Docker Compose project in cloud‑native infrastructure, handling secrets, networking and more for you. In this post we’ll walk through the n8n sample template and show how you can deploy a production‑ready n8n instance on your own AWS account in just a few commands.

Why build with n8n?

Flexible AI workflow automation – n8n lets you build multi‑step agents either by dragging nodes on a canvas or by writing code. You’re free to integrate any large‑language model and over 500 third‑party integrations. The platform explicitly supports running your own AI models and even hosting the entire stack on‑premises. This flexibility is why organisations as different as Wayfair, Microsoft and the United Nations have adopted it.
Self‑host on your own terms – by default n8n uses SQLite, but the project supports PostgreSQL and other production databases. You can enable SSL, control connection pools and even run the editor behind your own domain. You can also supply a custom encryption key so credentials stored in the database remain secure.

The Defang n8n template

The Defang sample for n8n adapts the official n8n Docker Compose example to fit Defang’s deployment model. At its core, the project contains two services:

A PostgreSQL container to persist workflow data.
An n8n container configured to connect to the database and expose the UI on port 5678.

Defang takes this Compose file and wires it into your chosen cloud provider. Secrets such as the database password and encryption key are stored outside of Git using defang config, and Defang provisions DNS, certificates and load balancers for you.

Step 1 – Generate the project

Start by installing the Defang CLI. The CLI lets you scaffold a sample and deploy it:


# Install the CLI (mac/linux - see https://docs.defang.io/docs/getting-started for Windows++)
. <(curl -Ls https://s.defang.io/install)

# Generate the n8n project in an empty folder
cd ~/my-projects
defang generate

During generation you can search for n8n and give your project a name. This creates a directory containing the Compose file and a README.md with instructions.

Step 2 – Configure secrets

n8n uses a database password and an encryption key to secure credentials. Defang stores these values in your cloud’s parameter store. The sample exposes the following environment variables:

Variable	Purpose	Recommended value
POSTGRES_PASSWORD	Password for the Postgres database	Generate a random value with defang config set POSTGRES_PASSWORD --random docs.defang.io
N8N_ENCRYPTION_KEY	Key used by n8n to encrypt credentials	Generate a random value with defang config set N8N_ENCRYPTION_KEY --random
DB_POSTGRESDB_SSL_ENABLED	Enables SSL when connecting to the database	true in production; false in local dev
DB_POSTGRESDB_SSL_REJECT_UNAUTHORIZED	Whether to reject unauthorized certs	false when using Amazon RDS without custom certificates, true locally

To configure these secrets run:

# Configure Defang  
export DEFANG_PROVIDER=aws 
export AWS_PROFILE=defang-lab # put in a valid profile from your aws config 

defang config set POSTGRES_PASSWORD --random 
defang config set N8N_ENCRYPTION_KEY --random  
defang config set DB_POSTGRESDB_SSL_ENABLED=true  
defang config set DB_POSTGRESDB_SSL_REJECT_UNAUTHORIZED=false

If you plan to deploy into your own AWS account, authenticate with the AWS CLI (by setting environment variables like AWS_PROFILE) before running Defang. You can also run the sample in the Defang Playground without any provider configuration.

Step 3 – Deploy

Deploying is a single command:


# Deploy to your AWS account (assuming your env vars from the 
# previous step are still in place.

defang compose up

Defang reads your Compose file, replaces any ${VAR} references with values from the Defang config, and spins up resources. Under the hood Defang provisions:

An ECS task (or equivalent) to run the n8n container.
An RDS instance to host PostgreSQL.
Route 53 entries for both internal service discovery and public access.
TLS certificates and load balancers to terminate HTTPS.

By comparison, manual self‑hosting would require you to set up Docker Compose on an EC2 instance, configure volumes and manage updates yourself. Defang automates that complexity and manages secrets using the provider’s secret manager.

After a few minutes the CLI will print the URL of your n8n instance. It will look something like https://n8n--5678.n8n.myusername.defang.app. Open it in your browser. n8n will prompt you for a username and password; you can skip personalisation if you don’t need it.

Step 4 – Create credentials in n8n

One of the most powerful features of n8n is its credential system. Credentials (e.g., OAuth for Google, Slack tokens, API keys) are stored encrypted in the database using the N8N_ENCRYPTION_KEY you set earlier. When adding a credential in the n8n UI you’ll see environment variables like N8N_HOST and N8N_PORT pre‑filled. These variables initially contain the service name (e.g., n8n:5678), but Defang automatically resolves them to the public DNS of your deployed service. Simply accept the suggested URL when configuring OAuth redirect URIs in Google or other providers.

For example, to configure Gmail you would:

Click Try a prebuilt agent → Email Triage Agent in the n8n UI.
Select Create new credential for Gmail.
Copy the callback URL shown (it should match the domain Defang created) into your Google Cloud OAuth configuration.
Complete the OAuth flow and test the agent.

What’s happening in AWS?

When you look into your AWS console you’ll see how Defang maps Compose concepts into native services:

The n8n container runs as a task in an ECS cluster. You can view logs and scale up tasks just like any Fargate workload.
PostgreSQL runs in Amazon RDS. You’ll find a managed database with backups, encryption and metrics enabled.
Route 53 hosts two DNS zones: a private zone used for internal service discovery (so the n8n service can reach the database via its Compose hostname) and a public zone for your application’s domain. Defang automatically creates A and CNAME records for you.
For local development you can run docker compose -f compose.dev.yaml up, which starts both services on your machine and exposes n8n at http://localhost:5678 .

This infrastructure makes it easy to go from a prototype to a production cloud deployment without hand‑crafting Terraform or Pulumi scripts.

Go further: build AI agents with n8n

With your self‑hosted n8n instance running, you can start building agentic workflows. The platform lets you combine code and UI: write JavaScript or Python directly in nodes, merge branches, call LLMs and integrate arbitrary APIs. You can also take advantage of n8n’s new Evaluations and Data Tables features to experiment with prompts and persist structured data.

Because you’re self‑hosting, your data never leaves your environment. You can connect n8n to internal services (databases, ticketing systems, CRMs) without exposing them to a third‑party SaaS. At the same time, Defang handles networking, certificates and more for you.

Conclusion

The combination of n8n and Defang gives you the best of both worlds: a powerful AI orchestration platform and a painless way to run it in your own cloud. n8n’s recent funding round underlines how important orchestration and coordination are for real‑world AI applications, while Defang’s deployment model removes the DevOps burden. By generating the n8n sample, configuring a handful of secrets and running defang compose up, you can stand up an instance of n8n in your AWS account in minutes.

We’d love to see what you build. Clone the sample, deploy it to your cloud of choice and share your workflows with the community. Whether you’re triaging emails, automating incident response or orchestrating agents, this template is a solid foundation.

Beyond Heroku: Owning Your Deployments

Defang.io — Mon, 29 Sep 2025 11:26:30 +0000

When you launch a new app, convenience rules. Platforms like Heroku offer a beautifully simple way to push code and see it live in minutes. You don’t need to think about servers, networks or databases. You just deploy. That’s why so many of us start there.

But convenience has a cost. As your product grows, you want more control over performance and security. You want to integrate your own services, tune the infrastructure and optimize your spend. Heroku’s dyno‑based pricing, which starts around $25/month for a modest dyno and climbs to hundreds of dollars for high‑performance dynos, can become prohibitive for serious production workloads. And while Heroku abstracts away the underlying cloud, that abstraction also means you can’t fine‑tune the way your application runs.

This trade‑off eventually becomes untenable. Teams need the simplicity of a platform like Heroku and the power and trust of running inside their own AWS account. This post unpacks why migrating off Heroku matters, highlights the friction points when you try to move to AWS yourself, and shows how the Defang CLI bridges the gap.

Heroku vs. AWS

Heroku is a Platform‑as‑a‑Service very focused on simplicity and ease of use, while AWS offers a huge array of extremely powerful services that can be difficult to navigate alone. What you get from Heroku is the ability to deploy your application with a simple git push, scale by adding dynos and pick from a marketplace of add‑ons. But you miss out on much of the power of AWS, like the ability to organize and network services the way you want, the ability to deploy in a huge number of regions, their reliability, and much of the control you need to be called enterprise-ready. AWS also tends to be more cost effective as you scale and offers a wide variety of scalable storage options including Postgres, MongoDB, Redis, and more.

Pricing and scale

Heroku’s pricing is tied to dynos. Eco dynos cost about $5/month for 1,000 hours, while standard dynos run $25–$50/month and performance dynos jump to $250–$1,500/month. Those numbers are predictable, but if your traffic spikes or you need more compute, your dyno bill scales quickly. Databases and Redis add‑ons are also billed per gigabyte, adding to the total cost.

AWS uses a pay‑as‑you‑go model: you pay for the exact resources you use, whether on‑demand compute, reserved instances or spot capacity. This model can be far cheaper at scale, especially if you commit to reserved or savings plans, but it also introduces complexity. Besides compute, you need to factor in elastic IPs, data transfer, load balancers and NAT gateways. AWS rewards expertise: you can optimize costs but only if you understand its pricing levers.

Why leave Heroku?

For many teams, Heroku is the right starting point. But there are clear inflection points when it makes sense to graduate:

Escalating costs.
As your user base grows, dyno bills rise exponentially. At some point, the predictable price premium no longer justifies the convenience.
Performance and scalability demands.
High‑traffic applications need flexible scaling and the ability to choose instance sizes and storage types. Heroku’s dyno types can be limiting for CPU‑ or memory‑intensive workloads.
Compliance and data sovereignty.
Customers in regulated industries often require apps to run in their own cloud account and under their own compliance controls.
Customization.
You might need to integrate bespoke networking, private databases or other services not available as Heroku add‑ons. AWS’s vast ecosystem of more than 240 services makes these integrations possible.

Yet the path off Heroku isn’t trivial. Re‑platforming often means rewriting your application to use AWS services directly, building new CI/CD pipelines, managing IAM roles and provisioning infrastructure by hand. That’s a big lift for developers who just want to ship features.

Migration in minutes: how the Defang CLI works

In our recent video (“How to migrate from Heroku to AWS in 5 minutes!”), we demonstrated a Django + Postgres app running on Heroku. The goal: deploy it into our own AWS account without rewriting anything. Here’s how it works:

Import your Heroku app.
After installing and logging into the Defang CLI, run:

defang init

Then select Migrate from Heroku.

Defang connects to the Heroku API, inspects your app’s dynos, add‑ons and configuration variables, and generates a Docker Compose file. It translates Procfile commands into services and records dependencies like Postgres and Redis.

Review the Compose file.
You should always examine the generated compose.yaml. You can adjust ports or remove unnecessary services. In the demo we changed the exposed port to 8000 and confirmed everything looked reasonable.

Select your cloud.
We authenticated against AWS and selected a profile (AWS_PROFILE=defang-lab). In Defang, you set a provider with an environment variable DEFANG_PROVIDER=aws.

You can either export these, or pass them to each command:

AWS_PROFILE=defang-lab DEFANG_PROVIDER=aws defang <command>

Or you can set them as environment variables:

export AWS_PROFILE=defang-lab DEFANG_PROVIDER=aws

Set your secrets.
You then run defang config set to provide any secrets (database user, password, database name) that were previously stored in Heroku. These secrets are encrypted at rest and passed securely to your services deployment.

Deploy with one command.
Finally, execute:

defang up

Defang provisions an ECS cluster, RDS database, VPC, security groups, DNS records, load balancer, and more for your application. It also provisions a release service to handle migrations and brings up your web service once the database is ready. Eventually you get a public URL for your working application.

Verify and scale.

The entire migration took roughly five minutes from start to finish, with zero changes to application code. Instead of rewriting our Django settings or learning the intricacies of ECS, we let Defang automate the heavy lifting.

Why this matters

The migration from Heroku to AWS delivers two critical advantages that matter most to growing teams: cost savings and power and flexibility.

As we covered earlier, Heroku's dyno pricing can quickly escalate from $25/month to hundreds or even thousands as you scale. AWS's pay-as-you-go model, combined with reserved instances and spot capacity, can reduce your infrastructure costs by 60-80% at scale (depends on your use case). You pay only for what you use, when you use it.

More importantly, you gain access to AWS's full ecosystem of 240+ services. Need a specific instance type for CPU-intensive workloads? Custom networking for multi-region deployments? Advanced monitoring and logging? On Heroku, you're limited to what's available in their add-on marketplace. On AWS, you can integrate any service, tune performance at the infrastructure level, and architect solutions that simply aren't possible on a PaaS.

For some teams, there's also the benefit of deploying into customer cloud accounts for compliance and data sovereignty requirements.

Defang bridges this gap by giving you Heroku-like simplicity with AWS power.

Try it yourself

If your team is outgrowing Heroku or you need to bring your application into your customers’ cloud, give our migration workflow a spin. Install the Defang CLI, run defang init migrate-from-heroku, and watch your app come to life in AWS. You can find more details in our official migration guide. We’d love to hear what you deploy and what features you’d like us to add next.

Deployments in the Agentic Era

Defang.io — Tue, 16 Sep 2025 16:44:51 +0000

If you want people to adopt your AI product, the deployment story has to be as strong as the features.

Over the past few decades, the software industry has gone through multiple major transitions. Each one reshaped not only how products are delivered, but also how they are trusted.

In the Client-Server Era (circa 2000), apps like SAP and PeopleSoft were purchased and deployed by the customer in their own "on-prem" environment. The customer was in control, but also took on the operational complexity of everything from procuring and deploying hardware to the system software and the apps themselves.
In the SaaS Era (circa 2010s), apps such as Salesforce and Workday ran in the provider's cloud and were delivered through the browser. While this simplified operations for the customer, it also meant that the customer data was trapped in these applications, with sometimes ambiguous data ownership and usage rules.
Today, we are entering the Agentic Era. Agentic apps promise to deliver an unprecedented productivity boost, but to do so, they need access to the most sensitive business data: conversations, documents, decisions. Customers do not want to transfer such data to an unknown and untrusted external provider's environment. Instead, they expect these products to run inside their cloud accounts (whether it be AWS, GCP, or any other), with their compliance, and under their security controls.

This is not a small adjustment. It is the foundation of how the next generation of software will be trusted and adopted.

Why the Agentic Era Changes the Rules

AI products are not like SaaS tools. They do not just manage workflows, they ingest and act on the crown jewels of a business. To succeed in this environment, three conditions must hold true:

Data stays with the customer: no leaking sensitive content outside their environment.
Deployments work across clouds: AWS, GCP, Azure, or wherever the customer operates.
Security and compliance are built in: IAM, networking, and policies set up correctly from day one.

This is not a technical detail. It is the trust layer that determines whether adoption happens at all.

ekai's Example

ekai is an AI digital twin that boosts productivity by capturing meetings, surfacing action items, and acting as a Slack companion. To be trusted, it has to run inside the customer's cloud account.

ekai needed a single deployment solution that could run on any cloud and deliver a consistent, reliable experience with the same features everywhere. Like many AI builders, they faced the challenge of providing secure, compliant deployments across AWS, GCP, and other environments without spending weeks on custom DevOps for each customer.

That is where Defang came in.

With Defang, ekai defines its application once in Docker Compose. Defang turns that definition into a production-ready deployment inside the customer's own cloud account. Compute, storage, networking, IAM roles, security groups, and even managed LLMs are provisioned automatically, following best practices for each cloud.

What used to take weeks of engineering now happens in hours. More importantly, every deployment is secure, compliant, and customer-owned.

"Defang was the ideal choice for us. We simply describe ekai as a Docker Compose application, and Defang takes care of everything else. From compute and storage to IAM roles and managed LLMs, Defang ensures our deployments are secure, scalable, and cloud-native. That is a huge benefit for us and for our customers."

Ash Tiwari, Founder & CEO, ekai

Defang and the Agentic Era

ekai is not an isolated case. It is a preview of what the Agentic Era demands. As AI products move deeper into mission-critical workflows, deployment will decide adoption.

Defang exists to make this possible.

Define your app once, no matter the framework: CrewAI, LangGraph, AutoGen, Strands
Deploy to any cloud in a single step
Keep customer data inside customer environments
Align deployments with cloud-native best practices automatically

Just as SaaS platforms unlocked a decade of cloud adoption, Defang is the foundation for customer-owned AI.

The Takeaway

In the Agentic Era, trust is the product. The next wave of AI adoption will be decided not by features, but by where and how products run. Companies that respect data ownership and deliver secure, cloud-native deployments will earn trust and scale. Those that do not will be left behind.

Defang is the invisible infrastructure making this era possible.