Deutsche Telekom is already running applications in its own AWS account through Lovable, according to the company. The deployment moves application infrastructure into the customer’s environment while Lovable continues to operate both the deployment stack and the service used to build and manage applications.
Lovable announced Deploy on AWS on October 14, 2026. It is a private preview for select Enterprise customers, not a generally available self-hosted edition.
For enterprises evaluating AI products against sensitive-data policies, the preview addresses where production applications execute and where their data resides. It does not establish that every interaction with the builder, including prompts and model requests, stays inside the customer’s network.
The Application Stack Moves Into the Customer’s Account
Lovable’s announcement describes a customer-account data plane: the infrastructure that runs application workloads, stores application data and connects applications to other systems.
That deployment includes:
- An Amazon EKS cluster running the Lovable data plane, including preview sandboxes used during development.
- Published application assets in Amazon S3, with dynamic requests handled by AWS Lambda.
- An Amazon Aurora PostgreSQL database and S3 application storage.
- Application logs, which can be sent to customer-controlled destinations such as S3 or Amazon CloudWatch.
- A connector gateway and the secrets used for integrations.
Preview sandboxes move into the customer’s account along with the published application. The execution environment used while iterating on an app is therefore part of the deployment.
The following is a logical boundary map of the announced architecture, not a subnet-level network diagram. AWS services are grouped by account responsibility rather than represented as running inside EKS.
LOVABLE'S MULTI-TENANT SERVICE
Editor and agent
Chat and project history
Workspace settings, identity and billing
Build-time AI model processing
Management runner endpoint
^
|
Outbound mTLS connection
from customer environment
|
CUSTOMER'S AWS ACCOUNT
Dedicated application VPC
EKS data plane and preview sandboxes
Aurora PostgreSQL
Connector gateway and integration secrets
Published application services
S3 static assets and application storage
Lambda dynamic request handling
Application logs
EC2-based Lovable management runner
PRIVATE INTEGRATION PATH
Application VPC
<---- VPC peering ---->
Connected VPC hosting internal systems
Data warehouse, CRM or HR systems
Application infrastructure and development-service infrastructure remain separate. A database in the customer’s account does not imply that the agent generating code also runs there. Moving previews into that account leaves the browser-based editor and project conversations with Lovable.
Lovable says it installs, manages and updates the components deployed in the customer’s environment. Customers gain account-level placement and visibility without being expected to operate the entire platform themselves.
VPC Peering Provides the Route to Internal Systems
According to Lovable, applications can reach internal systems, such as a data warehouse or CRM, over VPC peering without requiring those systems to be exposed on the public internet.
This private integration path is separate from the customer deployment’s connection back to Lovable, which supports the managed service. Lovable illustrates the integration path with a leave-planning application that needs access to an internal HR system. Under the proposed architecture, the application and its database run in the customer’s AWS environment, while the HR system is reached over the private connection.
Security teams have a more specific architecture to review than “the app connects to our data.” The design identifies the application environment, connector gateway, integration secrets and network path as distinct parts.
Peering does not, by itself, settle which records an application should access or which users should see them. Those remain application and access-policy questions. The preview changes where the integration runs; it should not be read as blanket approval for every application built against a sensitive system.
The Editor and Build-Time AI Still Cross the Boundary
The announcement’s most consequential qualification is what stays with Lovable: the editor, agent, chat and project history remain in its multi-tenant service, along with workspace settings, identity and billing. AI model requests made while building applications continue to be processed by Lovable’s AI service.
An enterprise therefore needs to assess at least two data flows separately:
- Application operation: where the application executes, stores records and accesses internal systems.
- Application development: what developers put into conversations and what information is processed through build-time AI requests.
A customer could satisfy a requirement to keep production application data in its own AWS account while still needing restrictions on what employees submit to the builder. Pasting a sensitive record into a development conversation does not become customer-account processing simply because the resulting application will run there.
Lovable says chat and project history are encrypted at rest. It also describes a bring-your-own-key option through which administrators connect an AWS KMS key and can revoke Lovable’s access. This provides a separate control over information held with Lovable. It does not establish that those records reside in the customer-hosted application stack.
The announcement does not establish that build-time inference moves into the customer’s account, and its statement about build-time requests does not fully describe every possible runtime AI integration. Any application that uses AI after publication needs a separate review of those flows.
Lovable Manages the Stack Through a Customer-Account Runner
Setup begins with an administrator creating a new Enterprise workspace and selecting AWS hosting. Lovable generates a CloudFormation stack for the customer to review and run.
The stack creates the VPC, an EC2 instance for the Lovable runner and the permissions that runner requires. The runner then provisions EKS, Aurora PostgreSQL, S3 and the other supporting services.
Lovable describes the runner as the mechanism through which it manages the installation while giving customers visibility into its actions. Separate IAM roles cover setup, routine maintenance and decommissioning. The company says the runner communicates with only one external host: Lovable’s runner endpoint.
The announcement also says components in the customer’s account connect outward to Lovable through an mTLS-encrypted tunnel, without Lovable needing an inbound connection into the customer’s network. The runner’s endpoint restriction should not be mistaken for a statement that every application workload has identical network restrictions.
Updates arrive as versioned Helm charts referencing signed container images in the customer’s container registry, according to the deployment description. Security teams can inspect those concrete artifacts and permissions rather than rely solely on a promise that the environment is managed securely. These remain vendor-reported architecture and security claims; the announcement is not an independent audit of the deployment.
Lovable also says Enterprise controls apply, including SSO, SCIM, publishing restricted to workspace members by default, a security scan on every build and audit logs. Those controls supplement the account boundary. Customers still need to review the runner’s permissions and the information exchanged with Lovable.
Private Preview Leaves Important Adoption Questions Open
Select Enterprise customers can request access through their account teams or Lovable’s published preview contact. This is not a deployment option that every customer can enable today.
Feature parity is unfinished. Lovable explicitly says some features available on its own hosting are not yet available in customer-hosted deployments. It does not identify the missing features, so an organization cannot assume that an existing application or workflow will transfer unchanged.
Pricing, supported-region coverage and a general-availability timetable also remain unspecified. Before committing a production workload, customers need those details alongside the architecture review. They should establish the operational division of responsibility as well: who responds to incidents, how updates are scheduled and how decommissioning works in practice.
Deutsche Telekom’s deployment is a concrete adoption claim from Lovable’s announcement. It supports the conclusion that the company reports a live enterprise installation, without establishing broad availability or independent validation across different environments.
The strongest reason to consider Deploy on AWS is a policy requiring application workloads and data to reside in an account the enterprise owns. The preview is designed to address that requirement while retaining Lovable as the operator.
If a policy also requires the editor, agent, project history and build-time AI processing to remain entirely inside the enterprise environment, the announced preview does not meet it. Its value depends on whether the customer’s security policy permits the boundary Lovable has drawn.
Sources
- Deploy on AWSlovable.dev
