Lovable launches Deploy on AWS: apps and data move into the customer's VPC

Lovable has released Deploy on AWS in closed preview: enterprise customers can now run apps built in Lovable inside their own AWS account. Building still happens in Lovable's cloud editor, but the runtime, database, storage and logs move into a dedicated customer VPC. Deutsche Telekom, the first global enterprise customer, launched this configuration in October.

What exactly will live in your account

Until now, the answer to "where does the app run and where does the data live" was always the same: on Lovable's infrastructure. For most teams, that is enough. But if an internal tool needs data from an HR system or a data warehouse that policy says cannot leave the perimeter, the app fails the security review. Deploy on AWS targets exactly this scenario.

Lovable deploys the following set of components in the customer's VPC:

• the Lovable data plane on an Amazon EKS cluster, including the preview sandboxes where builds run during iteration;
• published apps: static assets in Amazon S3, with dynamic requests handled by AWS Lambda;
• the app database on Amazon Aurora PostgreSQL and file storage in S3;
• application logs, which can be sent to S3, CloudWatch or the customer's other systems;
• a connector gateway and secrets for integrations.

Access to internal systems, such as a DWH or CRM, goes through VPC peering, so those systems do not have to be exposed to the public internet. Lovable handles installation, maintenance and updates, so the customer's team does not need to administer its own cluster.

How installation and access work

An administrator creates a new Enterprise workspace and chooses AWS as the hosting location. Lovable generates a CloudFormation template, which the customer's team reviews and runs itself. The stack creates the VPC, an EC2 instance for the Lovable runner component and the permissions the runner needs. From there, the runner brings up EKS, Aurora, S3 and the remaining services on its own.

The runner serves as a tool for managing the installation, and the customer can see everything it does. Separate IAM roles cover setup, day-to-day maintenance and decommissioning, so the principle of least privilege applies at every stage. The only external host the runner talks to is its own endpoint at Lovable. Every component update ships as a versioned Helm chart that references signed container images in the customer's registry.

Enterprise controls carry over to this mode as well: SSO and SCIM, publishing limited to workspace members by default, a security check on every build and audit logs.

Where the data boundary lies

App data stays in the customer's VPC, under the customer's own encryption and AWS access policies. Components in the account connect outward to Lovable through an mTLS tunnel, and Lovable does not need an inbound connection into the customer's network. Chat and project history is stored on Lovable's side in encrypted form. With bring your own key, an admin connects their own AWS KMS key in the workspace settings and can revoke Lovable's access at any time.

The boundary does not cover the whole product, however. The editor, agent, chat, project history, workspace settings, identity and billing all remain in Lovable's multitenant service. Lovable's service also handles AI model requests during builds. If your prompts or project context fall under restrictions, you need to check that separately.

Deutsche Telekom connected Lovable through its internal AI platform, AskT. According to the company, teams there have already created thousands of apps and prototypes, and the most sensitive workloads require that apps and data never leave its own network. Telekom is now building employee platforms with its global HR team.

Where to start

The mode is available only to select Enterprise customers, and some Lovable hosting features are still missing from it: there is no full parity. Hosting on Lovable remains the default option, and judging by the description, many organizations will run two types of workspaces: one in their own AWS account for sensitive data, the rest on Lovable.

A practical sequence looks like this. First, list the apps that need restricted data and write down what your policy requires of the place they run. Then walk through the IT and security architecture with your Lovable account manager, or write to [email protected]. Separately, check whether you are comfortable with a setup in which Lovable handles model requests. The same day, the company announced a similar option for Azure.