Managed Dify hosting

AI and LLMOn-prem or your region

A builder for AI apps, agents and retrieval workflows that runs next to your documents and your models instead of at a platform vendor. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Dify

Licence: Dify Open Source License
Runs on: Your own hardware, or any of 10+ Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: dify.ai

Running Dify in production: what it takes

Pin and deploy the full stack
A Dify version we have run, with Postgres, Redis, pgvector, the sandbox and the SSRF proxy, reachable only on your private network behind the Pilae gate.
Fence the sandbox
Code nodes run in the sandbox. Outbound requests pass the SSRF proxy, with an allowlist you approve, so a workflow cannot reach an internal address nobody intended.
Connect models and documents
Model providers configured centrally, embeddings on a local model where documents are sensitive, knowledge bases built from the sources you name.
Back up apps, knowledge and files
Postgres, the vector store, uploaded files and each app exported as DSL go offsite nightly. Once a month we restore into a scratch environment and run a workflow against the restored knowledge base.
Upgrade in your window
Dify releases often and migrates its database on upgrade. The Pilae Agent tests the next version against a copy of your apps, writes the plan and applies it after a verified backup, once you approve.

What Dify is, and who runs it

Dify is a platform for building AI applications. In one console a team designs a chatbot, an agent that calls tools, or a multi-step workflow that retrieves from documents, calls a model, branches on the result and writes somewhere. Each app is published as a web interface, an embeddable widget or an API.

It covers the ground of the OpenAI Assistants API and of Azure AI Studio, with one difference that matters to a regulated organisation: the knowledge bases, the prompts and the run logs sit on your own machines. The model is a setting. An app can use a local model on your GPUs today and a hosted one for a different task, without being rebuilt.

Its licence adds two conditions to Apache 2.0, set out below. For an organisation building its own internal apps, neither one costs anything.

Operating it well means treating it as a platform, not a single app. Code nodes execute whatever a workflow author writes, so the sandbox and the SSRF proxy stay in place and restricted. Document indexing runs on workers and needs sizing. Upgrades migrate the database, so each one follows a verified backup. We run Dify on your premises or in Pilae Cloud, and the Pilae Agent plans every upgrade for your approval. Many teams pair it with n8n, which moves data between business systems and calls a Dify app when a step needs a model.

Dify is licensed under a modified Apache 2.0 with two added conditions. You may not use the source to operate a multi-tenant environment, where one workspace is one tenant, without written authorisation from LangGenius. And where you use the Dify front end, you may not remove or change the logo or copyright information in the console or in the apps it serves. A single-tenant deployment for your own organisation, which is what Pilae operates for you, is within the licence. White-labelling, or selling workspaces to your own clients, needs an agreement with LangGenius first, and we raise that before you plan around it.

Dify system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory: 4 vCPU · 8 GBDify states 2 vCPU and 4 GB as its minimum. With the plugin daemon, the code sandbox and real document indexing running, we size at twice that.
Database: PostgreSQLApps, workflows, conversations and workspace settings.
Queue and cache: RedisCelery workers take document indexing and long workflow runs off the API process.
Vector store: pgvector, Qdrant or WeaviateWe default to pgvector in the same Postgres, so there is one database to back up. A large knowledge base can justify a dedicated store.
File storage: S3-compatible bucket or local volumeUploaded documents and generated files. On a Pilae site it is a bucket in the same region.
Model backend: OpenAI-compatible endpoint, or provider keysvLLM or Ollama on your GPUs, or the hosted providers you allow. Dify connects to each through a plugin.

Migrating from OpenAI Assistants to Dify

An assistant built on the OpenAI Assistants API is instructions, files and tool definitions tied to one vendor, and OpenAI has replaced that API with its Responses API. Some rework is unavoidable either way. In Dify each assistant becomes an agent or a workflow app. The instructions copy across as they are. The files are re-uploaded into a Dify knowledge base, where you control chunking and the embedding model. Tool definitions become Dify tools or HTTP nodes. Code that called the Assistants API is pointed at the Dify API of the new app instead. The model behind it becomes a setting you can change later without a rewrite.

List the assistants that are called
API logs for the last ninety days, not the list in the dashboard. We rebuild what production actually uses.
Rebuild each one as a Dify app
Instructions, knowledge base and tools, with the model chosen per app. Every app is exported as a DSL file and kept in your repository.
Compare answers side by side
The same questions go to the old assistant and the new app. Differences are reviewed with the team that owns the use case before anything switches.
Switch the callers and close the old account
Each integration moves to the Dify API key of its app. The vendor account is closed once the last caller has moved.

What runs in a Dify deployment


api	Console and app API	Postgres, Redis, vector store, sandbox, plugin daemon
worker	Indexing and long workflow runs	Same as api
web	Console and published app front end	api only
sandbox	Runs Python and JavaScript code nodes	Outbound only through ssrf_proxy
ssrf_proxy	Filters outbound requests from workflows	An allowlist you approve
plugin_daemon	Model providers and tools as plugins	Model endpoints you configured
db · redis · pgvector	State, queue and embeddings	Private network only

Dify is a set of services, not one container. Two of them exist to contain the code that workflows run and the URLs they fetch. We keep both in place and restricted, because a workflow builder that can run arbitrary code needs a fence around it.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What running Dify costs

On Starter, Dify runs in Pilae Cloud for CHF 449EUR 479USD 559 a month, hosting and onboarding included. On Business, it is one of up to three apps for CHF 1,590EUR 1,690USD 1,990 a month, on your own servers or in Pilae Cloud. Enterprise is quoted. The plans set what each includes; these are the inputs that move the price around them.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Starter, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where machines are priced per month. On Starter, Pilae chooses the site.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Dify: common questions

Is Dify open source?

Its source is public and it is based on Apache 2.0, with two added conditions: no multi-tenant service without written authorisation, and no removal of the Dify logo or copyright information. Running it for your own organisation is within the licence. Reselling workspaces or white-labelling needs an agreement with LangGenius.

Can we sign in with our directory?

Single sign-on through OIDC or SAML inside the Dify console is part of the Dify Enterprise edition, which LangGenius licenses separately. On the community edition the console answers only on your private network, and joining that network requires a login through your identity provider. So only people from your directory reach Dify at all. If you need per-user SSO inside Dify itself, we arrange the Enterprise licence with you.

Does anything leave our network?

Only what you configure. With models and embeddings on your own GPUs, prompts and documents stay inside. A hosted model provider receives what is sent to it, and the SSRF proxy restricts which other addresses a workflow may call.

Can Dify run air-gapped?

Yes, with preparation. Model providers and tools are plugins that normally install from the Dify marketplace. For an air-gapped site we bring the plugin packages in offline and pair Dify with models served on your own hardware.

How does Dify differ from n8n?

Dify is built for AI applications: retrieval over documents, agents, prompt management and chat front ends you can publish. n8n is built for general automation between business systems. Many teams run both, with n8n moving data and calling a Dify app when a step needs a model.

What happens to our apps if we leave?

Every app is exported as a DSL file in your repository, and the database, knowledge bases and files are on your machines or your dedicated Pilae Cloud machines. You can import the apps into any Dify installation.

Back to apps

Bring us your Dify. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing