Dify deployment
Overview
This is Dify, set up to fit into my HomeAgents platform. Dify is the no code builder for AI apps and workflows. The upstream files come from release 1.17.1 under their Apache 2.0 licence, and I changed very little.
My changes are small on purpose. I pinned the image versions, closed every port that the default setup would publish and kept my own settings in one place. An upgrade then never surprises me.
The most useful decision is how Dify reaches models. It talks to my gateway as if it were OpenAI, and the gateway holds the real keys. So the app builder never sees one.
Problem
I wanted a no code builder for AI apps and workflows as part of my home platform. Dify already does the job, but its default setup publishes ports, drifts when images update and wants its own model keys. I needed it to fit my platform without opening anything up.
Approach
- I took the upstream Dify files from release 1.17.1 and kept them under their Apache 2.0 licence.
- I changed as little as possible. I pinned the image versions, bound every published port to the local machine and trimmed some comments.
- I kept Dify's own .env file and its own private networks, so it stays apart from the rest of the platform.
- I made the databases and stores switchable by a setting, so a change does not mean rewriting files.
- I wrote the README for the things that usually go wrong, such as the Linux host mapping and upgrades.
Architecture and design decisions
- Compose profiles decide which backing services start. Two settings in the .env file set the profiles, so moving from Weaviate to Qdrant or from PostgreSQL to MySQL is an edit to that file.
- The default setup runs nginx, the API, the worker, the web app, PostgreSQL 15, Weaviate, Redis, the sandbox, the plugin daemon and a Squid proxy that guards outgoing requests.
- Only nginx is exposed, and only on 127.0.0.1 port 8085.
- Dify reaches models through one OpenAI compatible provider that points at my LiteLLM gateway. No provider key ever enters a Dify container.
- Storage, database, Redis, the vector store, plugins, sandbox files and certificates all live under one data folder of the platform.
Reliability and performance
- Pinned image versions mean an upgrade never changes what runs by surprise.
- The README states that all Dify images must move to a new version together.
- Every port in the default profile is bound to the local machine.
- A backup is a copy of one directory, because all persistent data sits in the platform's data root.
- A certbot profile is documented for adding TLS.
Outcomes
- Dify runs as the app and workflow builder of my home platform.
- Switching the vector store or the database is a settings change.
- Provider keys stay out of the app builder, because it only knows the gateway.
- Upgrades are planned and repeatable.
- The repository is public, and the upstream licence is kept.
Known gaps
- Most of this repository is the upstream Dify setup. My part is the version pinning, the port binding, the settings and the documentation.
- I have not measured speed, memory use or how many apps it handles.
- I do not say which apps I built in Dify. This page is about the deployment.
- I have not shown a tested restore. The page only says where the data sits.
- The Qdrant and MySQL options come from the upstream design. I say they are switchable, but I do not claim I run them.