Additional Configuration

This page contains additional system configuration options that are provided for self-managed Appmixer installations. See the System Configuration for the rest of the configuration options. The options below can be set via the environment variables on the instances of the Appmixer engine.

API and Worker nodes

Appmixer 6.2 introduces the ability to easily start a pod as either an API node or a worker node. If you deployed Appmixer using the Helm Chart, no action is required—the chart already supports separate API and worker nodes.

Running an API node only

To run a node as an API node only, pass the --no-worker argument in your deployment configuration (engine.yaml):

...
    spec:
      containers:
        - args:
            - -c
            - node gridd.js --http --no-worker       ## API node only
          command:
            - /bin/sh
...            

Running a worker node only

To run a node as a worker only, do not use the --http argument. The pod must be started without any arguments.

You will need to create a separate deployment configuration for the worker node. This can be a copy of engine.yaml with the arguments removed:

...
    spec:
      containers:
        - args:
            - -c
            - node gridd.js         ## Worker node only
          command:
            - /bin/sh
...            

Logging

LOG_LEVEL

By default set to info. It can be changed to error, warn or debug.

LOG_COMPONENT_DATA_MESSAGE

When set to false, the component's input/output messages won't be logged into Elasticsearch.

Important! Appmixer Insights and Designer log messages won't contain any items if logging data messages are turned off.

LOG_STDOUT_ONLY

When set to true, all logs are sent to stdout only and RabbitMQ connection for logging is skipped. This is useful when using log aggregation tools like Vector, Fluentd, or Filebeat that read logs from stdout/stderr.

By default, Appmixer sends logs to RabbitMQ, which are then consumed by Logstash and stored in Elasticsearch. When LOG_STDOUT_ONLY is enabled:

• All logs (system logs, component data messages, flow logs) are written to stdout as JSON

• RabbitMQ connection for logging is not established

• Logs are written asynchronously using pino transport for non-blocking output

• Log aggregation tools can collect logs directly from container stdout

Default value: false

Example configuration:

  engine:
    ...
    environment:
      - LOG_STDOUT_ONLY=true
    ...

When using LOG_STDOUT_ONLY=true, you need to set up an external log aggregation solution (e.g., Vector, Fluentd, Filebeat) to collect and forward logs to your logging backend (e.g., Elasticsearch, Loki, CloudWatch).

If you enable LOG_STDOUT_ONLY without setting up log collection, logs will only be available in container stdout/stderr and will be lost when the container restarts unless your container runtime preserves logs.

Use Cases:

• Kubernetes deployments: Use Vector as a sidecar or DaemonSet to collect logs from all pods

• Docker Compose: Use Fluentd or Filebeat to aggregate logs from multiple containers

• Cloud platforms: Send logs directly to cloud-native logging services (CloudWatch, Stackdriver, Azure Monitor)

• Simplified architecture: Eliminate RabbitMQ and Logstash from the logging pipeline

APPMIXER_HTTPS_PROXY and APPMIXER_HTTP_PROXY

Configure an HTTP proxy. All HTTP(S) requests from Appmixer will be redirected to the proxy URL.

Token Encryption

Most of the connectors in Appmixer require user authentication. That can be represented as OAuth access tokens, API keys, or username/password combinations.

To enable token encryption, set the ENCRYPTION_ENABLED environment variable to true. With that, also set the ENCRYPTION_SECRET environment variable to a secret string (see below for an example on how to generate it).

# Turning the encryption on
ENCRYPTION_ENABLED=true
# Setting the encryption secret (generate your own!)
ENCRYPTION_SECRET=0EC0136A5187A09E21D03819A0EFFD259070CE23213B260A1444412EFD910503

# Generate the encryption secret
openssl enc -aes-256-gcm -k secret -P -md sha1
# copy the 'key' and put it to ENCRYPTION_SECRET

If you lose the encryption secret, you will not be able to recover the encrypted tokens.

MinIO/S3

Appmixer contains a MinIO plugin. If this plugin is turned on, Appmixer will store all user files (files created either through Appmixer flows or through the /files API) in the MinIO/S3 server.

The plugin cannot migrate existing files from MongoDB to MinIO. It has to be turned on when Appmixer is installed before the files are created. If you already have files in MongoDB and want to start using MinIO, you have to migrate the data.

To enable the plugin, add minio to the SYSTEM_PLUGINS (comma-separated list of plugins) ENV variable (this variable cannot be set dynamically through the Backoffice - System Configuration):

# Turning on the plugin
SYSTEM_PLUGINS=minio

# Required variables
MINIO_ACCESS_KEY=admin
MINIO_SECRET_KEY=secretKey
MINIO_ENDPOINT=192.168.1.8   # s3.amazonaws.com to connect to AWS S3

# Optional variables
# Default value set to 80 for HTTP and 443 for HTTPS.
MINIO_PORT=9000
# Set this value to 'true' to enable secure (HTTPS) access
MINIO_USE_SSL=true
MINIO_REGION=eu-central-1
# All files will be stored by default in the 'appmixer-files' bucket
MINIO_BUCKET_NAME=appmixer-files  

If you want to use AWS S3, use the following permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:ListBucketVersions",
                "s3:ListBucket",
                "s3:ListMultipartUploadParts",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::appmixer-files/*",
                "arn:aws:s3:::appmixer-files"
            ]
        }
    ]
}

Forgot Password Service

Appmixer provides an API to reset forgotten passwords. This works together with the Appmixer Studio interface (not the Appmixer SDK).

In order to create a link that can be sent to the user, the Appmixer engine needs to know the frontend URL, there are two variables that can be set for that:

Key	Detail	Default value	Required
APPMIXER_FE_URL	The Frontned URL	http://localhost:8080
RESET_PASSWORD_FE_URL_SUFFIX	URL path with the reset password form	reset-password

Without any changes, the link will be http://localhost:8080/reset-password?code={{code}}.

That link has to be then delivered to the user. There are two ways this can be done:

Webhook

You can register a system webhook that will be triggered every time a user requests to change their password. The webhook URL can be registered under the key WEBHOOK_USER_FORGOT_PASSWORD and the JSON object sent to that URL will be:

{
  "code": 'unique code generated for identifying forgot password request',
  "email": 'email address of the user',
  "userId": 'User Id',
  "created": 'date when a user requested for forgot password',
  "link": 'Link to access forgot password page on the frontend'
}

You can use Appmixer to create a simple flow, that would send emails with the reset password link.

SMTP

The other way is to configure the SMTP server, Appmixer will then send an email with the reset password link to the user's email address.

Key	Detail	Default value	Required
MAIL_SMTP_HOST	SMTP server address
MAIL_SMTP_PORT	SMTP server port	465
MAIL_SMTP_USER	username
MAIL_SMTP_PASS	password
MAIL_FROM_NAME	Sender name	Appmixer
MAIL_FROM_EMAIL	Sender email	[email protected]
FORGOT_PASSWORD_MAIL_SUBJECT	Reset password email subject.	Reset your password
FORGOT_PASSWORD_MAIL_BODY	The reset password email body.	See below

The default email body:

<p>Hi,</p>
<p>You have requested to reset your password. Please click on the link below to reset your password.</p>
<p><a href="{{link}}">Reset Password</a></p>
<p>If you are unable to click on the link, please copy and paste the following link into your browser:</p>
<p>{{link}}</p>

If the forgot password webhook is configured as explained above, the Appmixer engine will not send the email to the user and it will trigger the webhook instead.

User Signup Rate Limiting

To protect against abuse and ensure system stability, Appmixer provides rate limiting for the user signup API (POST /user). Rate limiting is automatically applied to unauthenticated signup requests (public user registration) and can be configured using environment variables.

Rate limiting only applies to unauthenticated signups. When an authenticated admin creates a user via the API, rate limiting is bypassed.

Configuration Variables

Appmixer implements two layers of rate limiting for user signups:

Email-Based Rate Limiting

Limits the number of signup attempts per email address to prevent spam and abuse.

Key	Detail	Default value	Required
USER_SIGNUP_RATE_LIMIT_EMAIL	Maximum signups per email address	10
USER_SIGNUP_RATE_LIMIT_EMAIL_WINDOW_MS	Time window in milliseconds	3600000 (1 hour)

Example:

USER_SIGNUP_RATE_LIMIT_EMAIL=5
USER_SIGNUP_RATE_LIMIT_EMAIL_WINDOW_MS=1800000  # 30 minutes

IP-Based Rate Limiting

Limits the number of signup attempts from the same IP address to prevent bulk registration attacks.

Key	Detail	Default value	Required
USER_SIGNUP_RATE_LIMIT_IP	Maximum signups per IP address	50
USER_SIGNUP_RATE_LIMIT_IP_WINDOW_MS	Time window in milliseconds	3600000 (1 hour)

Example:

USER_SIGNUP_RATE_LIMIT_IP=20
USER_SIGNUP_RATE_LIMIT_IP_WINDOW_MS=3600000  # 1 hour

Error Responses

When a rate limit is exceeded, the API returns a 429 Too Many Requests HTTP status with a descriptive error message:

Email limit exceeded:

{
  "error": "Too many signup attempts for this email address. Please try again later."
}

IP limit exceeded:

{
  "error": "Too many signup attempts from your IP address. Please try again later."
}

Best Practices

• Email limits should be set lower (5-10) to prevent abuse of specific email addresses

• IP limits should be set higher (20-100) to account for shared IPs (corporate networks, ISPs with NAT)

• Consider your use case:

  • Public SaaS applications: Use stricter limits (email: 3-5, IP: 20-30)

  • Internal/Enterprise applications: Use more relaxed limits or disable by setting very high values

  • Testing/Development: Set higher limits or use authenticated user creation to bypass rate limiting

If you have legitimate use cases for high-volume user creation (e.g., bulk imports, migrations), use an authenticated admin account to create users via the API, which bypasses rate limiting entirely.

Context Quotas

Components produce messages using the context.sendJson() function. An internal quota mechanism controls how many messages a user can produce.

This is the default configuration:

// QUOTA_CONTEXT_SEND
[
    {
        # 'user' can generate 100 messages per second (across all their flows)
        "limit": 100,
        "scope": "user",
        "windowInSeconds": 1,
        "name": "send:1s"
    },
    {
        # 'user' can generate 1000 messages per minute (across all their flows)
        "limit": 1000,
        "scope": "user",
        "windowInSeconds": 60,
        "name": "send:60s"
    },
    {
        # 'user' can generate 20000 messages per day (across all their flows)
        "limit": 20000,
        "scope": "user",
        "windowInSeconds": 86400,
        "name": "send:1d"
    }
]

// QUOTA_CONTEXT_SLOW_QUEUE
[
    {
        # 'user' can generate 100000 messages per minute (across all their flows)
        # everything that exceeds this limit will be thrown away
        "limit": 100000,
        "scope": "user",
        "windowInSeconds": 60,
        "name": "slowQueue:60s"
    },
    {
        # 'user' can generate 5000000 messages per day (across all their flows)
        # everything that exceeds this limit will be thrown away
        "limit": 5000000,
        "scope": "user",
        "windowInSeconds": 86400,
        "name": "slowQueue:1d"
    }
]

Each call to context.sendJson() increases the quota. If a limit is reached, the message is placed in a Slow Queue. Messages in the Slow Queue are processed at a much slower rate and only when sufficient resources are available. This ensures that one user's flows do not consume excessive resources and block other users.

User Scope-Based Quotas

You can define different quota limits for different user segments using the optional userScope field. This allows you to create tiered quota plans (e.g., free, premium, enterprise) or apply different limits based on user characteristics.

Configuration Example:

// QUOTA_CONTEXT_SEND with user scopes
[
    {
        "limit": 10,
        "scope": "user",
        "userScope": "free",        // Free tier users
        "windowInSeconds": 1,
        "name": "send:1s"
    },
    {
        "limit": 500,
        "scope": "user",
        "userScope": "premium",     // Premium users
        "windowInSeconds": 1,
        "name": "send:1s"
    },
    {
        "limit": 2000,
        "scope": "user",
        "userScope": "enterprise",  // Enterprise users
        "windowInSeconds": 1,
        "name": "send:1s"
    },
    {
        "limit": 100,
        "scope": "user",             // Default for all users
        "windowInSeconds": 1,
        "name": "send:1s"
    }
]

// QUOTA_CONTEXT_SLOW_QUEUE with user scopes
[
    {
        "limit": 100,
        "scope": "user",
        "userScope": "free",
        "windowInSeconds": 60,
        "name": "slowQueue:60s"
    },
    {
        "limit": 50000,
        "scope": "user",
        "userScope": "premium",
        "windowInSeconds": 60,
        "name": "slowQueue:60s"
    },
    {
        "limit": 200000,
        "scope": "user",
        "userScope": "enterprise",
        "windowInSeconds": 60,
        "name": "slowQueue:60s"
    },
    {
        "limit": 1000,
        "scope": "user",
        "windowInSeconds": 60,
        "name": "slowQueue:60s"
    }
]

Rule Selection Logic:

For each time window (userScope + windowInSeconds), the system selects the rule with the highest limit from:

1. Default rules (without userScope)

2. Rules matching the user's scopes

Note: The scope field is always set to "user" in context quota configurations.

Example: A user with scopes ['user', 'free', 'premium']:

• Available rules: default (limit: 100), free (limit: 10), premium (limit: 500)

• Result: The premium rule is selected (limit: 500) as it provides the most generous limit

This ensures users with multiple scopes always get the most favorable quota limits.

Setting User Scopes:

User scopes are set when creating or updating users through the API. Users can have multiple scopes assigned:

// Example: Creating a user with premium scope
{
    "username": "[email protected]",
    "scope": ["user", "premium"]
}

Use Cases for User Scopes

• Tiered Plans: Implement free, premium, and enterprise tiers with different resource limits

• Partner Programs: Provide higher limits to strategic partners or resellers

• Beta Testing: Grant increased quotas to beta testers or early adopters

• Custom Agreements: Set specific limits for individual customers with custom contracts

If you want to change the default values, you can use the Env variables QUOTA_CONTEXT_SEND and QUOTA_CONTEXT_SLOW_QUEUE, you can set them in the Backoffice.

QUOTA_CONTEXT_SEND default value, you can copy&paste this to the Backoffice and modify.

[{"limit":100,"scope":"user","windowInSeconds":1,"name":"send:1s"},{"limit":1000,"scope":"user","windowInSeconds":60,"name":"send:60s"},{"limit":20000,"scope":"user","windowInSeconds":86400,"name":"send:1d"}]

QUOTA_CONTEXT_SLOW_QUEUE default value, you can copy&paste this to the Backoffice and modify.

[{"limit":100000,"scope":"user","windowInSeconds":60,"name":"slowQueue:60s"},{"limit":500000

Garbage Collectors

Files

The garbage collector for files can be turned off with GC_FILES_ENABLED (set to false). The behavior can be controlled by a set of rules GC_FILES_RULES.

This is the default set:

[
    {
        scope: 'user',

        /**
         * The GC will never delete files created in the past fileTTL (in minutes). By default,
         * set to 720 hours. The reason is to prevent the GC from removing files that could be needed by the
         * flows.
         */
        ttl: 720,   // 30 days

        /**
         * The user will be blocked to save any files if the limit is reached.
         */
        hardLimit: 1000 * 1000 * 1000 * 2   // 2 GB in bytes
    }
]

The value of GC_FILES_RULES is a stringified array of rules. There can be a different rule for each scope of users. Each rule has to have exactly 3 properties - scope, ttl and hardLimit.

Example:

[{"scope":"user","ttl":720,"hardLimit":2000000000},{"scope":"admin","ttl":1440,"hardLimit":90000000000}]

In this example, the admin users can store files up to 90GB and their files will be deleted after 1440 hours (60 days).

When the users exceed the hardLimit, they he will not be able to create more files. To get unblocked, they must delete some of their files and get under the limit.

The garbage collector does not remove files uploaded via the Files API, or files marked as archived.