"en_US":"n8n is a powerful open-source workflow automation and conversational AI platform that blends the flexibility of coding with the simplicity of no-code development, empowering users to create efficient and secure automation workflows. It seamlessly connects any app with an API, leveraging native AI capabilities (like LangChain-based AI agent workflows) to process custom data, ideal for personal task management, team collaboration, or enterprise-grade automation. Its vibrant community offers over 400 integrations and 900+ ready-to-use templates, enabling users to deploy automations quickly.\n\nThe platform supports highly customizable workflow design, allowing users to write JavaScript/Python, add npm packages, or use an intuitive visual interface to manage data, catering to both simple tasks and complex processes. Enterprise-grade features like advanced permissions and air-gapped deployments ensure security, while multilingual support makes it accessible globally. n8n delivers a versatile and user-friendly automation solution.\n\nDiscover n8n’s Automation Scenarios\nn8n’s community resources provide extensive support and inspiration, helping users explore its scenario-based value and easily build automation workflows. Below are two key resources showcasing n8n’s capabilities across various use cases:\n\n1. [n8n Official Community Forum](https://community.n8n.io/): \nThe forum is a hub for user collaboration and learning, offering resources from beginner guides to advanced workflow designs. Shared use cases include automating social media posts or real-time data syncing, such as using n8n to pull data from Google Sheets and send Slack notifications, boosting team collaboration and data efficiency.\n\n2. [n8n Official Template Library](https://n8n.io/workflows/): \nThe template library offers over 900 ready-to-use workflows for scenarios like marketing automation, data analytics, and customer support. For example, a template can link Shopify to Mailchimp, automatically adding new customers to mailing lists and sending welcome emails, making automation accessible to non-technical users. AI-driven workflows, like handling customer queries with LangChain, highlight n8n’s strength in intelligent interactions.\n"
"upstream_behavior":"The source definition deploys the complete Docker Compose application model.",
"native_lxc_behavior":"The source model is preserved and remains blocked until every service option has a reviewed native Proxmox mapping.",
"reason":"Catalog import must not imply runtime compatibility.",
"behavioral_impact":"No automatic installation before review.",
"validation":"pending-per-application"
},
{
"id":"rolling-latest-image",
"upstream_behavior":"A discovered Compose may pin a release tag or digest.",
"native_lxc_behavior":"ProxMenux selects the same image repository with the latest tag for catalog installations.",
"reason":"The automatic catalog intentionally offers rolling latest images; pinned versions belong to the future manual installer.",
"behavioral_impact":"The installed release can be newer than the discovered Compose revision.",
"validation":"pending-per-application"
},
{
"id":"dedicated-lxc-network",
"upstream_behavior":"Docker publishes selected container ports on the Docker host.",
"native_lxc_behavior":"A reviewed native application will listen on its original container ports at a dedicated LXC address.",
"reason":"A native LXC has its own address and does not require Docker port NAT.",
"behavioral_impact":"Published ports are metadata; ProxMenux URLs use the matching container target port.",
"validation":"pending-per-application"
},
{
"id":"compose-shm-size",
"upstream_behavior":"Compose sets the size of the container /dev/shm tmpfs.",
"native_lxc_behavior":"ProxMenux mounts a native LXC tmpfs at /dev/shm with the same requested capacity.",
"reason":"The OCI image runs directly as an LXC and therefore needs the equivalent Proxmox mount entry.",
"behavioral_impact":"None expected.",
"validation":"not-requested-by-compose"
},
{
"id":"compose-command",
"upstream_behavior":"Compose replaces the image Cmd while retaining its Entrypoint.",
"native_lxc_behavior":"ProxMenux reads the official OCI Entrypoint and combines it with the Compose command as the native LXC init command.",
"reason":"Proxmox stores the effective OCI process as one entrypoint string.",
"behavioral_impact":"None expected.",
"validation":"not-requested-by-compose"
},
{
"id":"compose-privileged-mode",
"upstream_behavior":"Compose selects whether the container runs in privileged mode.",
"native_lxc_behavior":"ProxMenux uses a privileged LXC only after an explicit high-risk confirmation; otherwise it keeps the LXC unprivileged.",
"reason":"The native OCI-LXC deployment must preserve the requested privilege level without silently weakening isolation.",
"behavioral_impact":"A privileged LXC has weaker isolation from the Proxmox host.",
"validation":"native-equivalent"
},
{
"id":"compose-process-runtime",
"upstream_behavior":"Compose can replace Entrypoint, User and WorkingDir and request an init process or interactive terminal.",
"native_lxc_behavior":"ProxMenux applies the process overrides through native LXC init directives; lxc-init provides PID 1 supervision and the CT console provides terminal access.",
"reason":"The OCI process must start with the same identity, command and working directory without Docker.",
"behavioral_impact":"Compose stdin_open and tty become access through the Proxmox LXC console.",
"validation":"not-requested-by-compose"
},
{
"id":"compose-healthcheck",
"upstream_behavior":"Docker periodically executes the declared container healthcheck.",
"native_lxc_behavior":"For a single-service LXC, ProxMenux translates HTTP localhost checks into a mandatory first-start service check.",
"reason":"Proxmox has no persistent Docker health state, while the installer still must detect a failed first boot.",
"behavioral_impact":"The check runs during installation rather than continuously after installation.",
"validation":"not-requested-by-compose"
},
{
"id":"compose-cpu-priority",
"upstream_behavior":"Docker cpu_shares sets a relative scheduling weight with 1024 as its neutral value.",
"native_lxc_behavior":"ProxMenux converts the relative weight to Proxmox cpuunits with 100 as its neutral value and lets the user review it.",
"reason":"Both settings express relative CPU priority on different scales.",
"behavioral_impact":"Rounding and Proxmox minimum limits can slightly change very low weights.",
"validation":"not-requested-by-compose"
},
{
"id":"compose-network-identity",
"upstream_behavior":"Compose can set hostname, MAC address, extra hosts and attach a service to Docker networks.",
"native_lxc_behavior":"ProxMenux applies hostname and MAC to net0, writes additional host aliases into the LXC and uses its dedicated bridge connection for single-service networks.",
"reason":"A dedicated LXC has its own network namespace and does not need a Docker bridge per service.",
"behavioral_impact":"host-gateway resolves to the IPv4 address of the selected Proxmox bridge.",
"validation":"not-requested-by-compose"
},
{
"id":"docker-engine-metadata",
"upstream_behavior":"Compose labels annotate Docker objects and the json-file logging driver rotates Docker-managed logs.",
"native_lxc_behavior":"Labels remain source metadata; Docker json-file settings are not applied because the OCI process runs directly under LXC.",
"reason":"There is no Docker object or Docker json-file log behind a native OCI-LXC application.",
"behavioral_impact":"Docker-only label consumers and Docker log-driver rotation do not exist in the native deployment.",
"validation":"not-requested-by-compose"
},
{
"id":"compose-device-passthrough",
"upstream_behavior":"Compose passes host character devices or requests an NVIDIA runtime GPU.",
"native_lxc_behavior":"ProxMenux converts recognized device declarations to native Proxmox dev resources; NVIDIA profiles also inject compatible host driver libraries read-only.",
"reason":"Native OCI-LXC does not execute Docker device or NVIDIA runtime hooks.",
"behavioral_impact":"Hardware is exposed only after explicit user confirmation and host-path validation.",
"validation":"not-requested-by-compose"
},
{
"id":"compose-host-ipc",
"upstream_behavior":"ipc: host shares the Docker host IPC namespace, commonly to avoid Docker's small default shared-memory allocation.",
"native_lxc_behavior":"The application keeps the LXC IPC namespace and receives a configurable 1 GiB /dev/shm instead of sharing Proxmox host IPC.",
"reason":"Processes in a single native LXC already share one IPC namespace; retaining isolation is safer than exposing host IPC.",
"behavioral_impact":"The application cannot exchange IPC objects with processes on the Proxmox host.",
"validation":"not-requested-by-compose"
}
]
},
"compatibility":{
"automatic_install_candidate":true,
"validated":false,
"supported_compose_keys":[
"command",
"container_name",
"cpu_shares",
"deploy",
"devices",
"entrypoint",
"environment",
"extra_hosts",
"healthcheck",
"hostname",
"image",
"init",
"ipc",
"labels",
"logging",
"mac_address",
"network_mode",
"networks",
"ports",
"privileged",
"restart",
"runtime",
"shm_size",
"stdin_open",
"stop_grace_period",
"tty",
"user",
"volumes",
"working_dir"
],
"untranslated_blockers":[],
"policy":"Single-image definitions are installable when every declared Compose option has a native Proxmox translation. Multi-image and unsupported runtime features remain blocked until their orchestrator or mapping is available."
