Skip to content

Documentation

How Deployz works, in detail

Requirements, supported AWS architecture, connector access, data handling, the deployment lifecycle, and billing.

Getting started

  1. 01

    Connect GitHub. Deployz uses a GitHub App with read-only access to repository contents and metadata. It analyzes the repository and gives a readiness report: what passed, what needs input, and what blocks deployment.

  2. 02

    Configure and build a release. Enter the required settings and fix issues in your code. Deployz can write fix instructions for your own coding agent. It does not change your repository. Build a versioned release from a commit. You can also keep one free test deployment per application in your own AWS account.

  3. 03

    Your customer connects AWS. Send your customer an installation link. They review the plan, the resources, the AWS cost estimate, and the requested IAM actions, then launch the connector as a CloudFormation stack from their own AWS console. They do not need a Deployz account. Customers can install only while your subscription is active.

  4. 04

    Deploy and manage updates. Deployz creates the infrastructure and deploys the release. You start each later update and rollback.

Requirements

  • Your repository is on GitHub.
  • The repository has a Dockerfile that builds a production image. This is required. There is no buildpack.
  • The application returns a 2xx response on an HTTP health-check path, such as /health. A deployment becomes ready only after this check passes.
  • Migration and scheduled-job commands run through sh, so the image must include a shell.
  • Each customer has an AWS account. The person who launches the connector can create a CloudFormation stack that includes IAM roles.
  • Container images are Linux x86-64. ARM64 is not supported.

Supported architecture

Deployz supports one application architecture on AWS. Each deployment keeps the set of resources it was created with (see Updates and removal).

Application
One container image built from your Dockerfile. It runs as a web service on Amazon ECS (Fargate) behind an Application Load Balancer. Optional background workers run from the same image with a different command. Workers have no public URL. An optional one-time migration command runs before each release starts.
AWS Regions
Each customer environment runs in one AWS Region. You choose the Region when you create the deployment. The product shows the Regions that are available for installation.
Database
Optional. Amazon RDS for PostgreSQL 16 or RDS for MySQL 8.0, encrypted, in private subnets. Automated backups are kept for 7 days and deletion protection is on. Deployz creates a database only when the analysis finds that the application needs one.
Cache
Optional. One Redis-compatible node (Amazon ElastiCache for Valkey). TLS connections, AUTH, cluster mode, and Redis Stack modules are not supported.
File storage
One Amazon S3 bucket for each environment. Object storage only. Attachable disk volumes are not available.
HTTPS and custom domains
Each deployment gets an HTTPS URL on a deployz.dev subdomain. Traffic to this default URL passes through the Deployz Cloudflare proxy before it reaches the load balancer in the customer account. One custom domain per deployment is optional: the customer adds two DNS records, and traffic to the custom domain goes directly to their load balancer. The default URL stays available.
Networking
A new, dedicated VPC for each customer environment, with public and private subnets and a NAT gateway. The database and cache run in private subnets.
Scheduled jobs and queues
In preview. Deployz provisions an SQS queue or a scheduled job only when the analysis finds strong evidence in your code or configuration. You cannot declare them by hand.

Not currently supported

  • Cloud providers other than AWS
  • Kubernetes and serverless applications
  • Deployment into an existing customer VPC
  • More than one container image, or separate services that need their own Dockerfile
  • Databases other than PostgreSQL and MySQL, such as MongoDB and SQLite
  • Message brokers such as Kafka and RabbitMQ, and FIFO queues
  • Attachable persistent disk volumes
  • GPU workloads and ARM64 images

AWS access and the connector

How it connects

The customer launches the Deployz connector as a CloudFormation stack in their own AWS account. Deployz never asks for AWS access keys.

The connector is an AWS Lambda function. About every minute, it checks in with Deployz over outbound HTTPS to get instructions and report status. Deployz has no inbound path into the account.

Permissions

  • The permissions are substantial. The connector creates network, compute, database, cache, storage, and IAM resources for the application.
  • Most write actions are limited to resources tagged for the installation, and the connector role has a permissions boundary.
  • The CloudFormation execution role that the connector uses can create IAM roles for the application and has no permissions boundary.
  • The connector cannot read application logs.
  • Before connecting, the customer can review every requested IAM action on the installation page.

Connector updates and removal

When a new connector version is available, the customer updates the connector stack in their AWS console. Deployz cannot update it for them. An outdated connector can block release verification until it is updated.

To revoke access, the customer deletes the connector stack. Remove the deployment and its retained data first. After the connector is deleted, Deployz cannot change or remove the application.

Data and secrets

What Deployz receives

  • Installation ID, AWS account ID, and AWS Region
  • Connector version, and the release and image version that runs
  • Deployment state, infrastructure status, health state, and timestamps
  • Resource identifiers
  • AWS error messages, such as stack events, stopped-task reasons, and exit codes
  • Health-check status code and response time (not the response body)

What Deployz does not receive

  • Your application runtime and its in-memory data
  • Database data
  • Cache contents
  • S3 data
  • Application CloudWatch logs

Deployz does not automatically copy your raw application logs outside your AWS account.

Secrets

Secrets you enter are sent to Deployz over HTTPS and stored encrypted until your AWS account connects. Deployz then delivers them to AWS Secrets Manager in your account and deletes the active copy. If your account does not connect within 24 hours, the secret is deleted and must be entered again. Encrypted backup copies may remain for up to 7 days. Deployz does not display secret values or write them to application logs.

Values that you, the software provider, set for every customer are stored encrypted in Deployz.

Code, builds, and AI

Deployz builds release images in its own AWS account from your repository. It stores them in a Deployz container registry. The customer account pulls the image.

Analysis runs rule-based checks first. When they leave a question open, such as an unclear start command, Deployz can send a few repository files to an AI service. Values that look like secrets are redacted first, and sample environment files are reduced to key names.

AI answers must match a strict schema and only fill gaps; they never replace a value the checks found. The report marks AI values as inferred by AI so that you can verify them, and lower-confidence answers stay suggestions. Deployz's own compiler creates the CloudFormation template from a fixed set of supported AWS resources. AI does not create infrastructure or change deployments.

Privacy Policy Data Processing Addendum

Updates and removal

You start each update. Customer environments do not update automatically. The first successful installation deploys your newest ready release.

The migration command runs first. If it fails, no service is updated and the previous release continues to run. If a new version fails its health check, the previous version continues to run.

Rollback redeploys an earlier release. It does not reverse database migrations or change customer data.

A deployment keeps the resources it was created with. If a new release needs a database, cache, worker, queue, or schedule that the deployment does not have, or a different database engine, Deployz refuses the update. Create a new deployment for that release.

Removal

Remove deployment deletes the application, cache, load balancer, and most networking. It keeps the database (with deletion protection and automated backups), its credentials, the S3 bucket, and the network parts that the database uses. Retained resources continue to cause AWS charges.

Delete retained data is a separate step that you confirm. It needs the connector to be online. It permanently deletes the retained resources, with no final snapshot.

Last, the customer deletes the connector stack in their AWS console.

Billing

  • Price: $49 a month base plus $19 a month for each billable customer environment, in US dollars. Taxes may apply.
  • Free, with no card: sign-up, analysis, configuration, release builds, and one active test deployment per application in your own AWS account. That AWS account pays its own AWS costs.
  • The $49 base starts when you activate your subscription. Deployz asks you to subscribe when you start your first customer deployment, and customers can install only while the subscription is active. The base continues until you cancel, even with zero environments.
  • The $19 for an environment starts when it first becomes ready and stops when its removal starts. Paddle prorates partial months. An installation that never becomes ready has no $19 charge.
  • Updates, retries, and rollbacks have no extra charge.
  • If a payment fails or you cancel, existing environments keep running and you can still manage them, but you cannot start new customer deployments.
  • You manage invoices, payment details, and cancellation in the Paddle billing portal.
  • AWS bills the AWS account owner for infrastructure.
See pricing