Skip to main content
Dify Premium is our AWS AMI offering that allows custom branding and is one-click deployable to your AWS VPC as an EC2 instance. Head to AWS Marketplace to subscribe. It’s useful in a couple of scenarios:
  • You’re looking to create one or a few applications as a small/medium business and you care about data residency.
  • You are interested in Dify Cloud, but your use case requires more resources than supported by the plans.
  • You’d like to run a POC before adopting Dify Enterprise within your organization.

​
Access & Set up

After the AMI is deployed, access Dify via the instance’s public IP found in the EC2 console (HTTP port 80 is used by default). If this is your first time accessing Dify, enter the Admin initialization password (your EC2’s instance ID) to start the setup process.

​
Customize

​
Configuration

Use Docker Compose 2.35.0 or later. Run docker compose version to check.
1

Edit Environment Variables

Put each setting where Set a Variable says it goes:
  • Settings Compose reads first, such as COMPOSE_PROFILES and VECTOR_STORE, and the shared credentials go in /dify/.env.
  • Settings your AWS deployment already sets in docker-compose.override.yaml stay there.
  • Every other setting goes in a local .env file under /dify/envs/, never in a .defaults file.
For example, to change an OpenSearch setting, copy its defaults file once, then edit the copy:
2

Apply Changes

From /dify, validate the configuration and recreate the affected services. Keep your existing AWS override file in both commands; if it is absent, omit -f docker-compose.override.yaml.
If a change doesn’t take effect, check whether /dify/.env or docker-compose.override.yaml also sets it: both win over a local file (see Precedence).

​
Web App Logo & Branding

In Settings > Customization, you can remove the Powered by Dify branding or replace it with your own logo.

​
Upgrade

Choose a release from the Release Notes and read its upgrade guide before updating.
Run every Compose command below on your EC2 instance with the deployment’s existing project name and files, including any -p or COMPOSE_PROJECT_NAME. A different project name starts with new, empty named volumes. If you don’t have docker-compose.override.yaml, leave out its -f option.
1

Back Up the Deployment

  1. From /dify, stop the deployment so the databases aren’t writing while you copy their files:
    If you can’t stop it, back up the databases with their own dump tools instead.
  2. Back up /dify/.env, every local .env file under /dify/envs/, docker-compose.override.yaml, and other custom deployment files. Then back up persistent data, including /dify/volumes/ and any external databases or storage.
  3. If your deployment includes local_sandbox, also back up its named volumes, mounted at /home/dify and /workspace. List them with:
2

Update to the Selected Release

Replace <version> with the release tag you chose. Copy its Docker files and templates together:
The exclusions preserve your local environment files, AWS override file, and runtime data. Reapply changes to any other custom deployment files from your backup.
3

Review Your Configuration

Compare /dify/.env with /dify/.env.example, and each local file under /dify/envs/ with its new template. Where they differ:
  • Keep the values you set on purpose, including your database and vector store settings.
  • Take the template’s value for the rest.
  • Use the new name where the release notes rename a setting.
Don’t copy a template over your file: that discards your overrides.
If /dify/.env doesn’t set DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN yet, generate a value with openssl rand -hex 32 and set it there. The agent backend and its local sandbox require this shared token to start.
4

Apply and Check the Upgrade

Check that long-running services are Up or healthy and that init_permissions finishes with Exited (0). Then open Dify and check the features that use your custom settings.
Last modified on November 4, 2026