/work/dify-platform
// operable AI applications under constraint
A multi-tenant AI application platform adapted for restricted OpenShift, complete with two-layer observability that lets you debug AI failures the same way you'd debug infrastructure failures. Traces. Metrics. Logs.
It demonstrates how AI agents can be operated with the same review, observability, and deployment discipline expected from infrastructure in high-consequence environments.
> Fast delivery. Restricted environment. Observable by default.
// what it does
A multi-tenant marketplace where teams build chatbots, agents, and RAG pipelines without writing code: drag and drop components, connect to your data, and deploy.
A visual workflow builder plus chat interface, running in a self-managed environment with enterprise auth, observability, and self-hosted models.
// what users can build
Conversational AI with custom system prompts and personas
Visual multi-step pipelines with code execution nodes
Knowledge base Q&A with pgvector semantic search
Autonomous decision-making with tool orchestration
// fork enhancements
The reliability work around Dify: hardened deployment, identity, persistence, and observability for restricted OpenShift.
| Standard Dify | This Fork |
|---|---|
| Basic API keys | Keycloak SSO + OAuth2 |
| Optional PostgreSQL | EDB + pgvector (HA) |
| No LLM observability | Langfuse (built-in) |
| Docker Compose | Helm + ArgoCD + sync-waves |
| Public SaaS | Restricted OpenShift |
// request path
FIG.D1: identity-proxied, observable by default.
// the key to AI reliability
AI needs two observability layers. Infrastructure metrics tell you the system is healthy. LLM traces tell you the AI is working correctly. Most platforms give you one; you need both.
> This pattern applies to any LLM app. Without both layers, you have no visibility into why AI fails.
// sync-wave deployment
ArgoCD sync-waves orchestrate startup order so dependencies are ready before applications arrive.
// the dogfood
The MVP is a self-hosted assistant connected to a curated engineering corpus. Documentation, patterns, examples, and decisions become searchable through conversation.
The goal is practical: make platform and AI-delivery knowledge easier to inspect, reuse, and validate.
> The platform is useful only when the knowledge becomes reachable.
// why this is hard
No public registries. Every container image, chart, and dependency has to be mirrored, vendored, and reviewed.
FIPS cryptography. Standard TLS libraries don't work. OpenSSL FIPS module required. Most open-source projects assume normal crypto. Dify didn't.
OpenShift security context. No root. Arbitrary UIDs. Read-only filesystems. SecurityContextConstraints that block 90% of Docker Hub images out of the box.
Enterprise SSO. Identity, OAuth2 proxying, and certificate chains have to be treated as first-class platform work.
// stack
// the point
Observable AI infrastructure: the foundation reliability requires.
Two-layer observability gives you visibility into what AI is doing. Making it do the right thing consistently is the next problem.
> Step one: make it observable. Step two: make it reliable.