[FEATURE] Official Dockerfile and Image for Flowise Workers

[nikitas-novatix]

Describe the feature you'd like
Provide an official dockerfile.worker and a corresponding published Docker Hub image (e.g., flowiseai/flowise-worker) specifically for running Flowise workers. This would standardize and simplify deploying Flowise in scaled environments where the UI/API server and workers are separate processes.

Additional context
Running workers separately requires users to create custom Dockerfiles.
When deploying to Azure App Service:

• The standard flowiseai/flowise image is designed to run the UI/API server (its default command is effectively flowise start).
• Azure App Service provides a "Startup Command" field to override the image's default command.
• However, simply putting flowise worker in the App Service "Startup Command" often does not work reliably with the standard image. The platform's override mechanism can conflict with the image's existing ENTRYPOINT or CMD, which is built assuming flowise start. This frequently results in the container failing to start the worker process correctly.

A dedicated Dockerfile.worker with flowise worker set as its primary command/entrypoint avoids these platform-specific override conflicts entirely. It ensures the container is built specifically for the worker role, leading to more robust and predictable deployments.
I have successfully tested the following Dockerfile.worker in an Azure, confirming it resolves the startup command issue:

FROM node:20-alpine AS build

USER root

# Skip downloading Chrome for Puppeteer (saves build time)
ENV PUPPETEER_SKIP_DOWNLOAD=true

# Install latest Flowise globally (specific version can be set: flowise@1.0.0)
RUN npm install -g flowise

# Stage 2: Runtime stage
FROM node:20-alpine

# Install runtime dependencies
RUN apk add --no-cache chromium git python3 py3-pip make g++ build-base cairo-dev pango-dev curl

# Set the environment variable for Puppeteer to find Chromium
ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser

# Copy Flowise from the build stage
COPY --from=build /usr/local/lib/node_modules /usr/local/lib/node_modules
COPY --from=build /usr/local/bin /usr/local/bin

# Add a healthcheck.js file 
WORKDIR /app
RUN echo 'const express = require("express"); \
const app = express(); \
app.get("/", (req, res) => res.send("Flowise Worker Healthy")); \
app.listen(3000, () => console.log("Healthcheck running on port 3000"));' > healthcheck.js

# Install express
RUN npm install express

# Modified entrypoint to run both the worker and healthcheck 
# Sets the default command to 'flowise worker' running a healthcheck script alongside
ENTRYPOINT ["/bin/sh", "-c", "node /app/healthcheck.js & flowise worker"]

This works. However, there is another Redis issue that needs to be adressed: #2186 that causes the Flowise main and workers app because there is no keepalive mechanism with the redis queue. That needs to be adressed as well.

[HenryHengZJ]

We're using ECS to deploy service and workers, but we specify entryPoint = ["pnpm", "run", "start-worker"] and entryPoint = ["pnpm", "run", "start"] - that works well

[nikitas-novatix]

We're using ECS to deploy service and workers, but we specify entryPoint = ["pnpm", "run", "start-worker"] and entryPoint = ["pnpm", "run", "start"] - that works well

@HenryHengZJ I tried that with Azure App Services using docker-compose deployment but it doesn't seem to work and is nearly impossible to debug (no logs).

Would you mind if I made a PR with my Dockerfile.worker and updated the doc to specify it's to use for Azure App Service deployment ?