October Security Series

The biggest threat to your application’s data is not always a sophisticated attacker. Sometimes it’s a well-intentioned developer trying to meet a deadline. Entity Access Rules is one of the most powerful security features in Mendix, yet it’s often configured only after a security error appears on the screen.

In this blog, we’ll break down Entity Access Rules from the ground up, explain what every permission does, and work through common business scenarios to demonstrate how secure access can be implemented without compromising usability.

At some point, we’ve all encountered this in Studio Pro:

No access to entity 'Module.Entity' for user role 'User'

You open the Entity Access Rules and select all roles, create, delete, and set read and write to all attributes.

Error gone. Problem solved. Or is it?

What have you done?

For a problem with a lock, you removed all the doors in the house!

Surprisingly, many developers use Entity Access Rules every day without fully understanding what each permission controls.

Entity Access Rules

It is a set of rules that defines what an end user is allowed to do with the data. Simply, controlling which user can read, write, create and delete objects of an entity.

1. Create
   Controls whether the selected role can create new objects of an entity.
2. Delete
   Controls whether the selected role can delete objects of an entity.
3. Read
   Controls whether the selected role can read the attribute of an entity.
4. Write
   Controls whether the selected role can write the attribute of an entity.

Entity Access Rule Editor Section

Module Roles
Section to select module roles to which the access rule will be applied.

Access Rights
Section to select the access for the selected users.

XPath Constraint
Section to specify conditions at attribute or association level using XPath.

Scenario 1

Administrator can be able to create, delete, read and write but User can only be able to read.

In the above case, we need to create 2 Access Rules, 1 for Administrator and 1 for User.

Scenario 2

All users can read the project details except for certain sensitive attributes that hold client details, but they can be read only by the user who created it.

In the above case, we need to create 2 Access Rules: 1 for the user who created the project and 1 for other users.

Scenario 3

User can be able to read only the leave request submitted by them and should not be able to edit it once submitted.

In the above case, we need to create 1 Access Rule to create and read requests.

Decision Tree

1. Create
   Would the user need to create new records?
2. Delete
   Would this record ever be removed by this user?
3. Read
   Would the user need to see this field?
4. Would the user need to change this field?

What If?

1. What if there are no access rules specified?
   Mendix follows the principle of least privilege, so everything is restricted by default. So, the entity without any access rules can’t be accessed by any user.
2. What if create access is provided but with no write access?
   Mendix treats create as a special case; it allows writing to attributes even when there is no write access. Write access will only take effect on data that is already there in the database.
3. What if, in Generalization, the parent entity has no access rules, but the child entity has access rules?
   In Generalization, access rules of the parent entity are ignored, and both access to parent and child is controlled through the child entity. There is 1 special case where System.User entity access rules are always applied to its child entity.
4. What if I didn’t give read access to one or more attributes?
   Attributes with no read access are not sent to client; when you do retrieve them, they will be shown empty.
5. What if I create multiple access rules for the same role?
   Access rules are additive; there is no condition that will select only one or execute in a specific order. So if there is 1 read rule and 1 write rule for a role, now the role can perform both read and write.
6. What if cascading delete is configured to delete B when A is deleted but there is no delete access rule set for entity B?
   Even though cascading delete is configured, Mendix always respects entity access rules, so cascade will fail, and both A and B won’t be deleted.

Conclusion

Entity Access Rule is not a bug fix mechanism; it is not there to make Studio Pro stop complaining.

Every checkbox represents a business decision; every permission affects data security.

Let me know if you’d like further adjustments or additional points for the blog post!

Have you learnt something new today? Leave a like and share the blog for better visibility. Follow for more content.

Read more

• Access Rules
• User Roles
• Module Security

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Dear Developer, Giving Access to Everyone Isn’t a Great Idea was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

October Security Series

As organizations increasingly adopt low-code platforms, application security remains a shared responsibility. While Mendix provides robust built-in security capabilities, misconfigurations can still introduce vulnerabilities that expose sensitive data, APIs, and business processes.

In this Cybersecurity Month, let’s explore some common security misconfigurations in Mendix development and how developers can avoid them.

01. Overly Permissive Entity Access

One of the most common mistakes is granting excessive entity access to users who don’t need it.

Example: Giving ‘Employee’ role access to read all employee data when they only need to access their own data.

Risk

1. Unauthorized data exposure.
2. Regulatory compliance violations.
3. Insider threats.

Best Practice

1. Apply the ‘Principle of Least Privilege’.
2. Instead of broad access, use XPath constraints to only allow users to see relevant data.

02. Missing Page Access Restrictions

Developers often secure entities but forget to secure pages.

Example: An administrator page is accidentally accessible to standard users.

Risk

1. Access to sensitive functionality.
2. Exposure of confidential information.
3. Unauthorized modifications.

Best Practice

1. Review page access for every release.
2. Ask yourself:

• can users access this page?
• Should they access it?
• Is it restricted properly?

03. Insecure Anonymous User Configuration

Anonymous access is useful for public applications but frequently misconfigured.

Example: Allowing ‘Anonymous’ user to read, create data and to access microflows.

Risk

1. An attacker can read, write, or delete data without authentication.
2. An attacker can execute certain functionalities without authentication.

Best Practice

1. Disable anonymous user.
2. If enabled, restrict entity access and regularly test anonymous user capabilities.

04. Exposed APIs Without Proper Authorization

Many Mendix applications expose REST services for integration.

Example: API to validate user requests but without proper authorization.

Risk

1. Access to sensitive functionality.
2. Exposure of confidential information.

Best Practice

1. Implement Authentication and Authorization.
2. Implement Validation and Rate limiting.

05. Sensitive Data Stored In Plain Text

A dangerous but surprisingly common issue.

Example: Storing API keys, Access tokens, credentials, and Personal Information as plain text in a database.

Risk

1. Insider threats.
2. Database compromise leads to direct data exposure.

Best practice

1. Encryption of sensitive information.
2. Use a secure credential manager.
3. Implement a secret rotation policy.

06. Logging Sensitive Information

Logs help troubleshooting but can become a security liability.

Example: Logging of customer ID, name, and Email.

Risk

1. Insider threats.
2. Sensitive data exposure.

Best Practice

1. Log only events and errors.
2. Use only technical identifiers for identification.

07. Legacy Permissions

As applications grow, permissions often accumulate.

Example: A role created 3 years ago that is no longer required still has access to pages and some entities.

Risk

1. Exploit through forgotten or unmanaged permissions.

Best Practice

1. Perform regular access reviews.
2. Remove unused roles, pages, flows, and entities.

08. Outdated Marketplace Modules

Install Marketplace modules and never update them.

Example: Old version of Excel import module.

Risk

1. Known Vulnerabilities.
2. Compatibility issues.

Best Practice

1. Remove unused modules.
2. Upgrade marketplace content during the release cycle.

09. Insufficient Input Validation

Trusting user input too much.

Example: Allowing a user to enter a mobile number in the email input.

Risk

1. Injection attacks.
2. Data quality issues.
3. Business rule bypass.

Best Practice

1. Implement proper input validations.
2. Implement server-side input validations.
3. Sanitize user input.

10. Skipping Security Testing Before Release

Teams often focus heavily on functionality and performance while security receives minimal attention.

Example: Moving to production without security testing.

Risk

1. Unknown Vulnerabilities.

Best Practice

1. Conduct penetration testing.
2. Review logs.
3. Verify APIs.
4. Review user roles and access.

Conclusion

Mendix provides a strong security foundation, but even the best platforms can be undermined by poor configuration choices. Most security incidents are not caused by sophisticated attacks; they result from simple oversights such as excessive permissions, weak access controls, and insufficient testing.

This Cybersecurity Month, take the opportunity to review your Mendix applications and ensure security is built into every layer of your solution, from user roles and entities to APIs and deployment processes.

Let me know if you’d like further adjustments or additional points for the blog post!

Have you learnt something new today? Leave a like and share the blog for better visibility. Follow for more content.

Read more

• Security
• Security Recommendations

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Security Misconfigurations in Mendix Development was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quick Hack Series Part 7

In this part, we take the event we published in Part 1 and actually consume it in a second app. We import the AsyncAPI contract, let Studio Pro auto-generate the consumer entity and Handle_BE microflow, and wire up real logic that reacts when the event arrives. By the end, you'll have a full publish-to-consume round trip running locally against the Docker broker from Part 2.

Where We Left Off

• Part 1: Modeled a Business Event Service, defined the event contract, and published it from a microflow.
• Part 2: Stood up a local Kafka broker with Docker and pointed Studio Pro at it via ChannelName/ServerUrl constants.

Now it’s time to close the loop — build an app that actually listens for that event and does something useful with it.

Step 1: Get the AsyncAPI Contract from the Publisher

Back in your publishing app’s Business Event Service document, click Export AsyncAPI Document. This generates a YAML file describing the event’s name, attributes, and channel; this is the contract your subscriber app will import.

Copy this YAML file somewhere your subscriber app project can access it.

Step 2: Import the Event Service in the Subscriber App

1. In the consuming app, right-click the target module → Add other → Business Event Service.
2. Select Use an existing business event service.
3. Click Browse, select the YAML file you exported in Step 1.
4. Give the document a name (e.g. BE_LoanApplicationSubmitted_Consumer) → OK.

Studio Pro reads the contract and shows you the event’s structure — same attributes the publisher defined, ready to consume.

Step 3: Subscribe to the Event

After importing the AsyncAPI document, Mendix displays a panel where you can configure the subscription implementation. Navigate to the Subscribe section, click Add, and specify your Business Entity Name and Handler Microflow Name.

Studio Pro auto-generates two things for you:

• A persistable consumer entity in your domain model, mirroring the event’s attributes
• A Handle_BE microflow, placed in the same folder as the service document

This is the key difference from the publisher side: you don’t write the “receive” plumbing yourself. Studio Pro wires the entity and the trigger microflow automatically. Your job is just to fill in what happens after the event lands.

Step 4: Build Your Handle_BE Logic

Open the generated Handle_BE microflow. It already receives the consumed event object as an input parameter — from here, treat it like any other microflow trigger.

Typical patterns worth knowing:

• Simple record-and-store: commit the consumed entity as-is for audit/history purposes.
• Trigger downstream logic: read the event’s attributes and kick off your own business process — e.g., update a related record, send a notification, or call a REST action.
• Fan-out to multiple actions: split into decision branches based on event attribute values (e.g. status = “Approved” vs “Rejected”).

Step 5: Test the Full Round Trip Locally

With both apps configured to point at the same local broker (ChannelName=local, ServerUrl=localhost:9092 from Part 2):

1. Run the publisher app in Studio Pro, trigger the microflow that commits the published entity.
2. Run the subscriber app in Studio Pro (or have it already running).
3. Watch the subscriber app’s logs — you should see Handle_BE fire automatically once the event lands.

If you want to verify the message is actually flowing through Kafka before it even reaches your subscriber app, use the same console consumer command from Part 2:

docker exec kafka /bin/kafka-console-consumer --topic local --from-beginning --bootstrap-server kafka:19092

If you build this out yourself, I’d love to hear where you land; drop a comment with your use case!

Until next time, keep building and keep hacking!

Read more

Mendix Event Broker

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Building the Subscriber Side of Mendix Business Events was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

A verified Windows guide for Floci, K3s, PostgreSQL, S3, ingress-nginx, GitHub Container Registry, and ngrok

This guide walks you through building a complete local lab on Windows. It uses Floci to emulate AWS services, running a K3s cluster, PostgreSQL, and S3 storage on your own machine, with ngrok making the app reachable at a public HTTPS URL. By the end, you’ll have a running Mendix 11 app and a single script that restores the whole lab automatically every time you sign in to Windows.

Guide details

• Verified on: 13 September 2026
• Host: Windows 11 with Docker Desktop and WSL2
• Outcome: Mendix 11.13.0 runtime accessible through a stable public ngrok URL
• Recovery: One PowerShell script automatically restores the lab after Windows sign-in

Learn how to rebuild the lab from an empty Floci environment to a running Mendix application. Incorporate the corrections verified during the deployment: fixed Docker addresses, Kubernetes EndpointSlices, GitHub Container Registry authentication, a free ngrok Cloud Endpoint, and a restart automation that returned exit code 0.

Scope: This is a learning and demonstration environment. Floci emulates AWS services locally; it does not reproduce production AWS security, resilience, backups, networking, or service-level guarantees.

Successful final state

Verified component status

• Floci: Healthy at 172.20.0.6:4566 with persistent storage
• Kubernetes: Floci EKS-compatible K3s node is ready; context: floci-mendix
• PostgreSQL: Floci RDS container available at 172.20.0.3:5432
• S3 storage: Bucket mendix-floci-files accessible through the floci-s3 service
• Ingress: ingress-nginx configured with NodePorts 30080 and 30443
• Container registry: Private GitHub Container Registry repository configured with a Kubernetes image-pull secret
• Mendix application: Build and runtime are green, with 1/1 replicas running
• Public URL: https://completable-noncommemorational-terica.ngrok-free.dev/
• Restart task: Start Floci Mendix Lab completed successfully with LastTaskResult: 0

Architecture and fixed addressing

The public ngrok Cloud Endpoint forwards traffic to the local ngrok agent at default.internal. The agent sends traffic to localhost port 8080, where kubectl forwards it to ingress-nginx. Kubernetes routes the request to the Mendix runtime. The runtime reaches PostgreSQL and S3 through stable Kubernetes services backed by external EndpointSlices.

Internet HTTPS
-> ngrok Cloud Endpoint
-> ngrok agent default.internal
-> localhost:8080
-> ingress-nginx service port 80
-> Mendix Ingress and runtime
-> floci-rds:5432 and floci-s3:4566

Network address mapping

• 172.20.0.1: floci_default Docker network gateway
• 172.20.0.3: Floci PostgreSQL container
• 172.20.0.4: Floci K3s cluster container
• 172.20.0.6: Floci API and S3 emulator
• localhost:6500: K3s Kubernetes API endpoint
• localhost:8080: Local ingress port-forward
• localhost:4566: Floci API accessible from Windows

Prerequisites and security rules

• Docker Desktop with WSL2 enabled.
• AWS CLI, kubectl, Helm 3, mxpc-cli, and ngrok v3 available on Windows.
• A GitHub account and a private GHCR package path.
• A reserved ngrok free domain and an authenticated ngrok agent.
• Do not publish Namespace Secrets, GitHub tokens, ngrok authtokens, database passwords, subscription secrets, signed package URLs, or generated YAML containing credentials.
• Never run docker system prune --volumes or docker volume prune against this lab.

Create the persistent Floci foundation

Create the external Docker network

The Compose file uses an external network. Create it before you run docker compose.

docker network create `
  --driver bridge `
  --subnet 172.20.0.0/16 `
  --gateway 172.20.0.1 `
  floci_default

Verify the network configuration:

docker network inspect floci_default

Create persistent storage

New-Item -ItemType Directory -Force -Path "D:\Floci\data"

Create the Compose file

Save this as D:\Developer-Knowledge-Hub\01-Inbox\Floci\compose.yml. The fixed address prevents the S3 endpoint from changing after a restart.

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"
    environment:
      FLOCI_STORAGE_MODE: persistent
      FLOCI_STORAGE_PERSISTENT_PATH: /app/data
    volumes:
      - D:/Floci/data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      default:
        ipv4_address: 172.20.0.6

networks:
  default:
    external: true
    name: floci_default

docker compose -f "D:\Developer-Knowledge-Hub\01-Inbox\Floci\compose.yml" up -d
docker inspect floci-floci-1 --format "Status={{.State.Status}} Health={{.State.Health.Status}}"

Expected result: Status=running and Health=healthy.

Verify Floci services

Invoke-RestMethod “http://localhost:4566/_localstack/health" | ConvertTo-Json -Depth 10

Create and connect the K3s cluster

Create the emulated IAM role

$trustPolicy = '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"eks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'

aws iam create-role `
  --role-name FlociEksClusterRole `
  --assume-role-policy-document $trustPolicy `
  --endpoint-url http://localhost:4566 `
  --region us-east-1 `
  --no-cli-pager

Create the EKS-compatible cluster

aws eks create-cluster `
  --name mendix-floci-cluster `
  --role-arn arn:aws:iam::000000000000:role/FlociEksClusterRole `
  --resources-vpc-config "subnetIds=subnet-default-a,subnet-default-b,subnet-default-c,securityGroupIds=sg-default,endpointPublicAccess=true,endpointPrivateAccess=false" `
  --endpoint-url http://localhost:4566 `
  --region us-east-1 `
  --no-cli-pager

aws eks describe-cluster `
  --name mendix-floci-cluster `
  --endpoint-url http://localhost:4566 `
  --region us-east-1 `
  --query "cluster.{Status:status,Endpoint:endpoint}" `
  --no-cli-pager

Continue when the status is ACTIVE and the endpoint is https://localhost:6500.

Attach the K3s container to the fixed network

docker network connect `
  --ip 172.20.0.4 `
  floci_default `
  floci-eks-mendix-floci-cluster

If Docker reports that the endpoint already exists, inspect the existing address instead of reconnecting it.

Create the kubeconfig context

aws eks update-kubeconfig `
  --name mendix-floci-cluster `
  --alias floci-mendix `
  --endpoint-url http://localhost:4566 `
  --region us-east-1

kubectl config use-context floci-mendix
kubectl get nodes -o wide
kubectl get storageclass

Expected result: one K3s control-plane node is Ready and local-path is the default StorageClass.

Configure PostgreSQL and S3

Create PostgreSQL

aws rds create-db-subnet-group `
  --db-subnet-group-name mendix-rds-subnet-group `
  --db-subnet-group-description "Subnet group for Mendix PostgreSQL" `
  --subnet-ids subnet-default-a subnet-default-b subnet-default-c `
  --endpoint-url http://localhost:4566 `
  --region us-east-1 `
  --no-cli-pager

Prompt securely for the database password so it is not stored in PowerShell history:

$dbSecurePassword = Read-Host "Enter the PostgreSQL password" -AsSecureString
$dbPassword = [Runtime.InteropServices.Marshal]::PtrToStringAuto(
  [Runtime.InteropServices.Marshal]::SecureStringToBSTR($dbSecurePassword)
)

aws rds create-db-instance `
  --db-instance-identifier mendix-postgres `
  --db-instance-class db.t3.micro `
  --engine postgres `
  --allocated-storage 20 `
  --master-username mendixadmin `
  --master-user-password $dbPassword `
  --db-name mendixdb `
  --db-subnet-group-name mendix-rds-subnet-group `
  --vpc-security-group-ids sg-default `
  --no-publicly-accessible `
  --endpoint-url http://localhost:4566 `
  --region us-east-1 `
  --no-cli-pager

$dbPassword = $null
$dbSecurePassword = $null

Important: Floci API metadata may advertise 172.20.0.6:7001, but Kubernetes must connect to the actual PostgreSQL container on port 5432. Inspect the generated container and attach it to the fixed network.

$RdsContainer = docker ps -a --format "{{.Names}}" |
  Where-Object { $_ -like "floci-rds-*" } |
  Select-Object -First 1

docker network connect --ip 172.20.0.3 floci_default $RdsContainer

Create the PostgreSQL Kubernetes service

kubectl create namespace mendix-floci
kubectl create service clusterip floci-rds --tcp=5432:5432 -n mendix-floci
kubectl patch service floci-rds -n mendix-floci --type=merge --patch '{\"spec\":{\"selector\":null}}'

@"
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: floci-rds-external
  namespace: mendix-floci
  labels:
    kubernetes.io/service-name: floci-rds
addressType: IPv4
ports:
  - name: 5432-5432
    protocol: TCP
    port: 5432
endpoints:
  - addresses: ["172.20.0.3"]
    conditions:
      ready: true
"@ | kubectl apply -f -

The EndpointSlice port name must exactly match the generated Service port name 5432-5432. A different name can cause the Service DNS test to fail even when the direct IP succeeds.

kubectl run rds-service-test -n mendix-floci `
  --image=busybox:1.36 --restart=Never --rm -i `
  --command -- nc -zvw5 floci-rds.mendix-floci.svc.cluster.local 5432

Create S3 storage

aws s3api create-bucket `
  --bucket mendix-floci-files `
  --endpoint-url http://localhost:4566 `
  --region us-east-1 `
  --no-cli-pager

kubectl create service clusterip floci-s3 --tcp=4566:4566 -n mendix-floci
kubectl patch service floci-s3 -n mendix-floci --type=merge --patch '{\"spec\":{\"selector\":null}}'

@"
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: floci-s3-external
  namespace: mendix-floci
  labels:
    kubernetes.io/service-name: floci-s3
addressType: IPv4
ports:
  - name: 4566-4566
    protocol: TCP
    port: 4566
endpoints:
  - addresses: ["172.20.0.6"]
    conditions:
      ready: true
"@ | kubectl apply -f -

Register the namespace and install Mendix

Keep the existing Portal cluster registration if it represents this lab. Create or reuse the Kubernetes namespace mendix-floci, then add that namespace in Mendix on Kubernetes Cluster Manager. Use the cluster type Kubernetes because the actual node is K3s.

Mendix namespace installation page. Namespace identifiers and secrets must remain redacted.

Run the namespace installer

.\mxpc-cli.exe installer -n mendix-floci -i <NAMESPACE_ID> -s <NAMESPACE_SECRET>

In the installer, complete Base Installation. Verify that the Agent and Operator become healthy.

kubectl get pods -n mendix-floci -o wide

The namespace is connected after the Mendix Agent and Operator are running.

Install ingress-nginx and connect ngrok

Install ingress-nginx

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx `
  --namespace ingress-nginx `
  --create-namespace `
  --set controller.service.type=NodePort `
  --set controller.service.nodePorts.http=30080 `
  --set controller.service.nodePorts.https=30443 `
  --set controller.ingressClassResource.default=true

kubectl get pods -n ingress-nginx -o wide
kubectl get ingressclass

Expected result: ingress-nginx-controller is 1/1 Running and the nginx IngressClass exists.

Reserve and connect the ngrok domain

Reserve the free domain completable-noncommemorational-terica.ngrok-free.dev in ngrok. Configure the Cloud Endpoint to forward to https://default.internal. The public ngrok endpoint terminates TLS; Kubernetes ingress TLS remains disabled in this lab.

Reserved ngrok public Cloud Endpoint.

Start a local port-forward and keep the process running:

kubectl port-forward -n ingress-nginx service/ingress-nginx-controller 8080:80

In a second PowerShell window, start the ngrok agent from its installation directory:

.\ngrok.exe http 8080 --url https://default.internal

If ERR_NGROK_334 appears, an older ngrok process already owns the endpoint. Inspect and stop only that stale process, then run the correct command again.

Get-CimInstance Win32_Process |
  Where-Object { $_.Name -eq "ngrok.exe" } |
  Select-Object ProcessId, CommandLine

Configure Mendix plans and registry

Database plan

• Name: floci-rds-postgres
• Host: floci-rds.mendix-floci.svc.cluster.local
• Port: 5432
• Strict TLS: Off for the local emulator
• Database name: postgres
• Authentication: static
• Username: mendixadmin
• Password: Securely created RDS administrator password

The PostgreSQL database plan validates successfully with the configured master username.

S3 storage plan

• Name: floci-s3-storage
• Type: amazon-s3
• Endpoint: http://floci-s3.mendix-floci.svc.cluster.local:4566
• Bucket prefix: mendix-floci-files
• IRSA: Off
• Share bucket: Off
• Credentials: Use local emulator credentials only and mask them in screenshots

The Floci S3 storage plan validates through the Kubernetes service.

Ingress configuration

• Ingress type: kubernetes-ingress
• Domain name: completable-noncommemorational-terica.ngrok-free.dev
• Path: /
• Enable TLS: Off — ngrok provides public HTTPS
• Custom Ingress Class: On
• Ingress Class Name: nginx
• Set class as annotation: Off

Ingress uses the reserved ngrok hostname and nginx class.

GitHub Container Registry

Create a GitHub personal access token with read:packages and write:packages. Never put the token directly in a published command or screenshot.

• Registry type: generic
• Pull URL: ghcr.io
• Push URL: ghcr.io
• Registry name: sukhvindra-singh/mendix-resources
• Authentication: On
• User: sukhvindra-singh
• Password: GitHub personal access token — keep it masked
• Default service account: Enable Add credentials to pull secrets

Use only owner/repository in Registry Name. Do not enter a tag template in that field; Mendix creates the environment-specific tag.

Corrected GHCR configuration. The token remains masked.

Evaluate and apply the configuration

Evaluate Configuration should report Valid configuration for Storage Plan, Database Plan, Ingress, and Registry. Then select Write YAML and Apply Configuration. Treat the generated YAML as sensitive because it can contain credentials.

All four namespace resources pass configuration evaluation.

The installer successfully applies all namespace configuration.

Create a package and development environment

Build a deployment package

1. Open the app in Mendix Portal and go to Deployment, Environments, Deployment Packages.

2. Select Create Deployment Package.

3. Choose the main branch and the required revision.

4. Enter the semantic version and select Build this revision.

5. Wait for the package to show a green completed indicator.

Select the main branch for the deployment package.

Select the required main-branch revision.

Review the version and build the selected revision.

Create the Development environment

1. Select Create Environment and choose the newly completed package.

2. Keep the generated lowercase environment ID. The verified ID was a0y77t7f.

3. Set Environment Name and Purpose to Development.

4. Select namespace mendix-floci on floci-mendix-cluster.

5. Enter a valid Mendix subscription secret only if you have a licensed runtime. Never use a GitHub token in this field.

6. Choose XS resources, floci-rds-postgres, and floci-s3-storage.

7. Create the environment and wait for Build and Runtime to become green.

Fix the free ngrok hostname

Mendix normally prefixes the namespace domain with the environment ID. A free ngrok reserved domain covers the exact hostname, not an arbitrary environment subdomain. Set spec.appURL to the hostname only. Do not include http://, https://, or a trailing slash; Kubernetes rejects a scheme as an invalid Ingress host.

Use the generated environment ID shown by MendixApp:

kubectl get mendixapp -n mendix-floci

Apply the hostname-only override:

kubectl patch mendixapp a0y77t7f `
  -n mendix-floci `
  --type=merge `
  --patch '{\"spec\":{\"appURL\":\"completable-noncommemorational-terica.ngrok-free.dev\"}}'

The Operator should reconcile the Ingress and status. If it repeatedly restores the environment prefix, use the controlled sequence below.

kubectl scale deployment mendix-operator -n mendix-floci --replicas=0

kubectl patch ingress a0y77t7f -n mendix-floci --type=json `
  --patch '[{\"op\":\"replace\",\"path\":\"/spec/rules/0/host\",\"value\":\"completable-noncommemorational-terica.ngrok-free.dev\"}]'

kubectl patch mendixapp a0y77t7f -n mendix-floci --subresource=status `
  --type=merge `
  --patch '{\"status\":{\"appURL\":\"http://completable-noncommemorational-terica.ngrok-free.dev/\"}}'

kubectl patch mendixapp a0y77t7f -n mendix-floci --type=merge `
  --patch '{\"spec\":{\"appURL\":\"completable-noncommemorational-terica.ngrok-free.dev\"}}'

kubectl scale deployment mendix-operator -n mendix-floci --replicas=1

Wait for the Operator to become ready, refresh Mendix Portal, and confirm the Network, Storage, Database, Service Account, Build, and Runtime indicators are green.

Invoke-WebRequest `
  -Uri "https://completable-noncommemorational-terica.ngrok-free.dev/" `
  -UseBasicParsing

Expected result: StatusCode 200 and StatusDescription OK.

Verified final environment: infrastructure, build, and runtime checks are green, and the fixed URL is displayed.

The optional Licensed Runtime counter can remain 0 of 1 when no commercial runtime subscription is activated. It does not invalidate this local demonstration when the runtime is healthy and the application returns HTTP 200.

Troubleshoot GHCR image pulls

Symptom

The runtime pod reports ErrImagePull or ImagePullBackOff. Pod events contain failed to authorize and 401 Unauthorized for ghcr.io. If imagePullSecrets is empty, Kubernetes attempted an anonymous pull from a private package.

Diagnosis

kubectl describe pod <RUNTIME_POD> -n mendix-floci
kubectl get pod <RUNTIME_POD> -n mendix-floci -o jsonpath="{.spec.imagePullSecrets}"
kubectl get secrets -n mendix-floci
kubectl get pod <RUNTIME_POD> -n mendix-floci -o jsonpath="{.spec.serviceAccountName}"

Expected secret: mendix-registry-generic-secret. The verified runtime used the default service account.

Attach the pull secret

This Windows-compatible command preserves the JSON quotes passed to kubectl:

kubectl patch serviceaccount default -n mendix-floci --type=merge `
  --patch '{\"imagePullSecrets\":[{\"name\":\"mendix-registry-generic-secret\"}]}'

Delete only the failed runtime pod. Its Deployment recreates it with the pull secret.

kubectl delete pod <RUNTIME_POD> -n mendix-floci

Expected progression: ErrImagePull, ContainerCreating, then 2/2 Running. Temporary readiness HTTP 500 responses can occur while the Mendix runtime initializes.

Rotate the GHCR credential securely

$ghcrSecureToken = Read-Host "Enter the new GitHub token" -AsSecureString
$ghcrToken = [Runtime.InteropServices.Marshal]::PtrToStringAuto(
  [Runtime.InteropServices.Marshal]::SecureStringToBSTR($ghcrSecureToken)
)

kubectl create secret docker-registry mendix-registry-generic-secret `
  -n mendix-floci `
  --docker-server=ghcr.io `
  --docker-username=sukhvindra-singh `
  --docker-password="$ghcrToken" `
  --dry-run=client -o yaml | kubectl apply -f -

$ghcrToken = $null
$ghcrSecureToken = $null

Restore the lab automatically after restart

Docker containers and Kubernetes volumes persist, but ngrok and kubectl port-forward are host processes and do not reliably resume after Windows restarts. The verified startup script checks Docker Desktop, recreates the fixed network when absent, starts Floci/K3s/RDS, repairs fixed addresses, waits for Kubernetes and ingress, starts forwarding processes, and validates the public URL.

Create the script

Save the following as D:\Floci\scripts\Start-FlociLab.ps1. Adjust only ComposeFile or NgrokExe if the local paths differ.

$ErrorActionPreference = "Stop"

$ComposeFile = "D:\Developer-Knowledge-Hub\01-Inbox\Floci\compose.yml"
$NgrokExe = "C:\Users\sukhv\Downloads\ngrok-v3-stable-windows-amd64\ngrok.exe"
$DockerNetwork = "floci_default"
$K3sContainer = "floci-eks-mendix-floci-cluster"
$KubeContext = "floci-mendix"
$Namespace = "mendix-floci"
$PublicDomain = "completable-noncommemorational-terica.ngrok-free.dev"
$PublicURL = "https://$PublicDomain/"
$LogDirectory = "D:\Floci\scripts\logs"
New-Item -ItemType Directory -Force -Path $LogDirectory | Out-Null

function Test-Docker {
  docker info *> $null
  return ($LASTEXITCODE -eq 0)
}

function Start-ContainerIfStopped([string]$Name) {
  $exists = docker ps -a --filter "name=^${Name}$" --format "{{.Names}}"
  if ($exists) {
    $running = docker ps --filter "name=^${Name}$" --format "{{.Names}}"
    if (-not $running) { docker start $Name | Out-Null }
  }
}

function Set-FixedNetworkIP([string]$Name, [string]$RequiredIP) {
  $exists = docker ps -a --filter "name=^${Name}$" --format "{{.Names}}"
  if (-not $exists) { Write-Warning "Container not found: $Name"; return }
  $inspect = docker inspect $Name | ConvertFrom-Json
  $property = $inspect[0].NetworkSettings.Networks.PSObject.Properties[$DockerNetwork]
  if ($null -ne $property -and $property.Value.IPAddress -eq $RequiredIP) { return }
  $wasRunning = (docker inspect $Name --format "{{.State.Running}}") -eq "true"
  if ($null -ne $property) {
    docker network disconnect -f $DockerNetwork $Name | Out-Null
    if ($LASTEXITCODE -ne 0) {
      throw "Failed to disconnect $Name from $DockerNetwork."
    }
  }
  docker network connect --ip $RequiredIP $DockerNetwork $Name
  if ($LASTEXITCODE -ne 0) {
    throw "Failed to connect $Name to $DockerNetwork using $RequiredIP."
  }
  if ($wasRunning) { docker start $Name | Out-Null }
}

if (-not (Test-Docker)) {
  Start-Process "C:\Program Files\Docker\Docker\Docker Desktop.exe"
  $ready = $false
  foreach ($attempt in 1..60) {
    Start-Sleep -Seconds 2
    if (Test-Docker) { $ready = $true; break }
  }
  if (-not $ready) { throw "Docker Desktop did not become ready." }
}

docker network inspect $DockerNetwork *> $null
if ($LASTEXITCODE -ne 0) {
  docker network create --driver bridge --subnet 172.20.0.0/16 `
    --gateway 172.20.0.1 $DockerNetwork | Out-Null
}

$previousErrorActionPreference = $ErrorActionPreference
$ErrorActionPreference = "Continue"
$composeOutput = docker compose -f $ComposeFile up -d 2>&1
$composeExitCode = $LASTEXITCODE
$ErrorActionPreference = $previousErrorActionPreference
$composeOutput | ForEach-Object { Write-Host $_ }
if ($composeExitCode -ne 0) {
  throw "Docker Compose failed with exit code $composeExitCode."
}
Set-FixedNetworkIP "floci-floci-1" "172.20.0.6"

foreach ($attempt in 1..60) {
  $health = docker inspect floci-floci-1 `
    --format "{{if .State.Health}}{{.State.Health.Status}}{{else}}{{.State.Status}}{{end}}" 2>$null
  if ($health -eq "healthy") { break }
  Start-Sleep -Seconds 2
}

Start-ContainerIfStopped $K3sContainer
Set-FixedNetworkIP $K3sContainer "172.20.0.4"

$RdsContainer = docker ps -a --format "{{.Names}}" |
  Where-Object { $_ -like "floci-rds-*" } | Select-Object -First 1
if ($RdsContainer) {
  Start-ContainerIfStopped $RdsContainer
  Set-FixedNetworkIP $RdsContainer "172.20.0.3"
}

kubectl config use-context $KubeContext | Out-Null
$nodeReady = $false
$previousErrorActionPreference = $ErrorActionPreference
$ErrorActionPreference = "Continue"
try {
  foreach ($attempt in 1..150) {
    kubectl get nodes *> $null
    if ($LASTEXITCODE -eq 0) {
      kubectl wait --for=condition=Ready node --all --timeout=10s *> $null
      if ($LASTEXITCODE -eq 0) { $nodeReady = $true; break }
    }
    Start-Sleep -Seconds 2
  }
}
finally {
  $ErrorActionPreference = $previousErrorActionPreference
}
if (-not $nodeReady) {
  throw "The Kubernetes node did not become ready within five minutes."
}

kubectl rollout status deployment/ingress-nginx-controller `
  -n ingress-nginx --timeout=180s

$portForward = Get-CimInstance Win32_Process | Where-Object {
  $_.CommandLine -match "port-forward" -and
  $_.CommandLine -match "8080:80"
}
if (-not $portForward) {
  Start-Process (Get-Command kubectl).Source `
    -ArgumentList @("port-forward","--address","127.0.0.1",
      "-n","ingress-nginx",
      "service/ingress-nginx-controller","8080:80") `
    -RedirectStandardOutput "$LogDirectory\ingress-port-forward.log" `
    -RedirectStandardError "$LogDirectory\ingress-port-forward.error.log" `
    -WindowStyle Hidden
  Start-Sleep -Seconds 5
}

$ngrok = Get-CimInstance Win32_Process | Where-Object {
  $_.CommandLine -match "127.0.0.1:8080" -and
  $_.CommandLine -match "default.internal"
}
if (-not $ngrok) {
  Get-Process ngrok -ErrorAction SilentlyContinue | Stop-Process -Force
  Start-Process $NgrokExe `
    -ArgumentList @("http","http://127.0.0.1:8080",
      "--url","https://default.internal",
      "--log","$LogDirectory\ngrok.log","--log-format","json") `
    -RedirectStandardOutput "$LogDirectory\ngrok-output.log" `
    -RedirectStandardError "$LogDirectory\ngrok-error.log" `
    -WindowStyle Hidden
  Start-Sleep -Seconds 8
}

$runtimeReady = $false
foreach ($attempt in 1..60) {
  $pods = kubectl get pods -n $Namespace -o json | ConvertFrom-Json
  $runtimePods = @($pods.items | Where-Object {
    $_.status.phase -eq "Running"
  })
  foreach ($pod in $runtimePods) {
    $statuses = @($pod.status.containerStatuses)
    if ($statuses.Count -gt 0 -and
        @($statuses | Where-Object { -not $_.ready }).Count -eq 0) {
      $runtimeReady = $true
      Write-Host "Mendix runtime is ready: $($pod.metadata.name)"
      break
    }
  }
  if ($runtimeReady) { break }
  Start-Sleep -Seconds 10
}

$available = $false
if ($runtimeReady) {
  foreach ($attempt in 1..12) {
    try {
      $response = Invoke-WebRequest -Uri $PublicURL -UseBasicParsing -TimeoutSec 20
      if ($response.StatusCode -eq 200) { $available = $true; break }
    } catch { }
    Start-Sleep -Seconds 10
  }
}

if (-not $available) { throw "Public Mendix URL did not return HTTP 200." }
Write-Host "Floci Mendix lab is ready: $PublicURL" -ForegroundColor Green
kubectl get pods -n $Namespace

Validate the final script

The final restart-safe version contains three important corrections. Set-FixedNetworkIP disconnects only when a container is already attached. Docker Compose and the Kubernetes readiness loop temporarily tolerate expected native stderr while retaining explicit exit-code checks. The port-forward binds to 127.0.0.1 and ngrok targets http://127.0.0.1:8080, avoiding the IPv6 localhost failure at ::1. The script waits up to 10 minutes for the runtime before validating the public URL.

$syntaxErrors = $null
[System.Management.Automation.Language.Parser]::ParseFile(
  "D:\Floci\scripts\Start-FlociLab.ps1",
  [ref]$null,
  [ref]$syntaxErrors
) | Out-Null
$syntaxErrors

No output means the PowerShell syntax is valid. Run the script once before registering it.

powershell.exe -NoProfile -ExecutionPolicy Bypass `
  -File "D:\Floci\scripts\Start-FlociLab.ps1"

Create the hidden VBS launcher

Save this file as D:\Floci\scripts\Start-FlociLab.vbs. WScript launches the PowerShell recovery script with window style 0, waits for its exit code, and records all startup output without leaving a visible terminal open.

Set shell = CreateObject("WScript.Shell")

command = "powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command ""& 'D:\Floci\scripts\Start-FlociLab.ps1' *> 'D:\Floci\scripts\logs\scheduled-task.log'"""

exitCode = shell.Run(command, 0, True)

WScript.Quit exitCode

Run automatically at Windows sign-in

$taskAction = New-ScheduledTaskAction `
  -Execute "wscript.exe" `
  -Argument '"D:\Floci\scripts\Start-FlociLab.vbs"'

$taskTrigger = New-ScheduledTaskTrigger `
  -AtLogOn `
  -User $env:USERNAME
$taskTrigger.Delay = "PT2M"

$taskSettings = New-ScheduledTaskSettingsSet `
  -StartWhenAvailable `
  -ExecutionTimeLimit ([TimeSpan]::Zero) `
  -MultipleInstances IgnoreNew `
  -Hidden

$taskPrincipal = New-ScheduledTaskPrincipal `
  -UserId "$env:USERDOMAIN\$env:USERNAME" `
  -LogonType Interactive `
  -RunLevel Highest

Register-ScheduledTask `
  -TaskName "Start Floci Mendix Lab" `
  -Action $taskAction `
  -Trigger $taskTrigger `
  -Settings $taskSettings `
  -Principal $taskPrincipal `
  -Description "Restores the Floci Mendix lab two minutes after Windows sign-in" `
  -Force

# Disable the obsolete task that opened a visible PowerShell window.
Disable-ScheduledTask -TaskName "Mendix Local Startup"

Start-ScheduledTask -TaskName "Start Floci Mendix Lab"
Start-Sleep -Seconds 30
Get-ScheduledTaskInfo -TaskName "Start Floci Mendix Lab" |
  Select-Object LastRunTime, LastTaskResult, NextRunTime

Verified final result on 13 September 2026: LastTaskResult was 0 after an actual Windows restart. Docker starts at sign-in, the recovery task begins after a two-minute delay, the VBS launcher keeps PowerShell hidden, and the IPv4 port-forward and ngrok tunnel run without visible windows. The Mendix runtime reached 2/2 Running, Agent and Operator reached 1/1 Running, and the public URL returned HTTP 200.

Final validation and operating notes

CheckExpected resultdocker inspect floci-floci-1Healthy; floci_default=172.20.0.6docker inspect floci-rds-*floci_default=172.20.0.3docker inspect K3s containerfloci_default=172.20.0.4kubectl get nodesOne Ready control-plane nodekubectl get pods -n mendix-flociAgent 1/1, Operator 1/1, runtime 2/2kubectl get pods -n ingress-nginxController 1/1 RunningMendix PortalNetwork, Storage, Database, Service Account, Build, Runtime greenInvoke-WebRequest public URLHTTP 200 OKScheduled taskLastTaskResult 0

Normal startup behavior

• The Kubernetes API and containers can take several minutes to become ready after Docker Desktop starts.
• A runtime pod can temporarily report readiness HTTP 500 while Mendix initializes.
• The public URL is unavailable until both kubectl port-forward and the ngrok agent are running.
• Use 127.0.0.1 explicitly for both port-forward and ngrok; localhost can resolve to IPv6 ::1 and cause a refused private-leg connection.
• The exact free ngrok hostname supports one environment at a time. Multiple environment subdomains require a wildcard-capable domain or separate endpoints.
• The startup script writes host-process logs under D:\Floci\scripts\logs. Task Scheduler may remain “Running” while the script waits; LastTaskResult becomes 0 after completion.
• Keep Mendix Local Startup disabled. It is the obsolete duplicate task that opened a visible Administrator PowerShell window.

Safe recovery order

1. Run D:\Floci\scripts\Start-FlociLab.ps1.

2. Confirm the three fixed Docker addresses.

3. Confirm the floci-mendix context and Ready node.

4. Confirm ingress-nginx, Agent, Operator, and runtime pods.

5. Inspect only the failing component logs; never publish full secrets or unredacted custom resource YAML.

6. Validate the public URL with Invoke-WebRequest.

Read more

• Mendix on Kubernetes
• Running the Mendix Operator in Standard Mode

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Deploy Mendix on a Local Floci Kubernetes Lab was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Three ways to get one app to tell another app something happened. They are not interchangeable.

The scenario

An e-commerce platform cancels an order. Three other systems need to know:

• Shipping — stop the shipment
• Notifications — email the customer
• Analytics — log the cancellation

Option 1 — API calls

Order app → POST /shipping/cancel      → waits for 200 OK
Order app → POST /notifications/send   → waits for 200 OK
Order app → POST /analytics/log        → waits for 200 OK

Example: the Order app’s cancellation microflow calls three REST endpoints, one after another, each with the order ID in the request body. If the Notifications service is mid-deploy and returns a 503, the whole cancellation flow either fails or has to retry that one call — while the customer is sitting on a “cancelling your order…” spinner.

• Order app must know all three endpoints, by name, in advance
• All three must be online right now
• Add a Refunds service later → go edit the Order app’s cancellation microflow
• One slow responder → the whole chain slows down

Tightly coupled. Synchronous. Fragile at scale.

Option 2 — RabbitMQ

Order app → publishes to "order_exchange"
             routing key: "order.cancelled"
             payload: {"orderId": "4471", "reason": "customer_request"}

Example: the Order app publishes once to the exchange, with that routing key. A shipping_queue and a notifications_queue are both bound to order.cancelled. Both receive a copy. If the Notifications service happens to be down for maintenance, the message just sits in notifications_queue — nothing is lost, nothing retries on the Order app's side, and the Order app already moved on the moment it published.

• Order app doesn’t know who’s listening, or how many
• Consumers subscribe independently, by binding a queue to the exchange
• Add a Refunds consumer later → bind a new queue with the same routing key. Order app’s code: untouched
• A down consumer doesn’t block the publisher — the message just waits

Loosely coupled. Fire-and-forget. The broker is self-hosted.

Option 3 — Mendix Business Events

Order app → "Publish business event"
             Subject: "Order cancelled"
             Event data: $CancelledOrder (orderId, reason)
             → Mendix Event Broker → subscriber apps

Example: a Shipping app, built separately in Mendix, subscribes to the OrderCancelled event. Mendix auto-generates a Handle_BE_OrderCancelled microflow in that app. The moment the Order app's microflow publishes and commits successfully, the Shipping app's handler fires — no polling, no manual "check if anything's new" step on either side.

• Same loose-coupling idea as RabbitMQ, without touching Java or Docker
• Subscriber microflows fire automatically the instant the event lands
• Publishing rolls back automatically if the publishing microflow’s transaction fails

Loosely coupled and Push-based. Mendix runs the broker.

The catch with Business Events

• Mendix apps only. A non-Mendix system — a Java backend, a .NET service, a third-party SaaS webhook — cannot publish directly into it.
• Needs a paid Event Broker license to run in Mendix Cloud production.
• No self-hosting option for the broker piece — the infrastructure is Mendix’s, not the developer’s.

Side by side

Which one, when

• API call — a response is genuinely needed back, right now, from one specific system
• RabbitMQ — external or non-Mendix systems are involved, or the broker needs to be self-hosted
• Business Events — pure Mendix-to-Mendix, with no interest in building or running broker infrastructure

Read More

Mendix Event Broker

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Fire and Forget: Why Mendix Needed a Broker was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quick Hack Series Part 6 (Continued)

In my previous post on Business Events, we created a Business Event Service and published our first event from a microflow. But an event with nowhere to go isn’t very useful; that’s where the Event Broker comes in.

The Event Broker is the piece that actually moves your events between apps. It sits in the middle, receives what gets published, and delivers it to anyone subscribed. In this part, we’ll set up a local Event Broker using Docker, so you can model, publish, and test the full round trip entirely on your own workstation before touching Mendix Cloud or a licensed broker.

Note: you can still get your own Kafka cluster and use it for on-prem also.

Why You Need This Before You Can Test Anything

Studio Pro lets you define publishers and subscribers without a broker running — the modeling works fine. But the moment you actually run your app and hit that Publish Event activity, it needs somewhere to send the message. Locally, that “somewhere” is a Kafka broker running in Docker.

Prerequisites

• Docker Desktop installed and running
• Git (to clone the setup repo)
• A Mendix app with at least one Business Event Service already modeled (see Part 1 if you haven’t done this yet)

Step 1: Clone the Event Broker Tools Repository

Mendix publishes an official helper repo that spins up Kafka and Zookeeper locally with a single command:

git clone https://github.com/mendix/event-broker-tools.git

This gives you a local-setup folder containing a docker-compose.yml that's pre-configured for Mendix Business Events modeling.

Step 2: Start the Local Broker

Navigate into the local-setup folder and run:

docker-compose up

Docker will pull the required images (Zookeeper and Kafka) and start both containers. You should see something like this in your terminal once it’s up:

[+] Running 2/2
 ✔ Container zk     Running
 ✔ Container kafka   Running

Leave this terminal open — this is your local broker running in the foreground. You’ll see periodic controller log lines (leader election checks) every few minutes; that’s completely normal steady-state Kafka behavior, not an error.

Tip: If you see InvalidReceiveException warnings early on referencing a Docker network IP, don't worry — that's typically just Kafka rejecting a malformed probe against the port, not something from your Mendix app.

Step 3: Point Studio Pro at the Local Broker

Back in Studio Pro, the Business Events module reads two constants to know where to send and receive events:

1. Open the BusinessEvents module and open the UseMe folder -> Local; there you will see a constant called ChannelName. Set it to ‘local’.
2. Open the Security module and set the ServerUrl to localhost:9092

This is the default when Docker Desktop runs natively on Windows or macOS — no VM IP lookup needed for most setups)

Step 4: Run and Test

Start your Mendix app in Studio Pro using this configuration, then trigger the microflow that publishes your event (from Part 1’s PBE_LDMScript example, or whatever entity you've modeled).

To confirm the event actually landed on the broker, you can watch the topic directly from your terminal:

docker exec kafka /bin/kafka-console-consumer --topic local --from-beginning --bootstrap-server kafka:19092

Note the port here is different from what you set in Studio Pro — 9092 is the listener exposed to your host machine, while 19092 is Kafka's internal listener used for container-to-container traffic (in this case, the console consumer running inside the same Docker network).

If everything’s wired up correctly, you’ll see your event’s JSON payload — including the CloudEvents-standard headers we touched on in Part 1 — show up in this terminal the moment your microflow commits the published entity.

What’s Next

With the broker running locally, you’re set up to test publishing end-to-end. In Part 3, we’ll build the subscriber side — importing the AsyncAPI contract exported from your publishing app, and wiring up the auto-generated Handle_BE microflow to actually react to the event.

Give this a try, and let me know how it goes — drop a comment if you hit any snags getting your local broker running!

Until next time, keep building and keep hacking!

Read more

• Mendix Event Broker
• Mendix Business Events

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Setting Up the Event Broker for Mendix Business Events was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

How One npm Command (And a Lot of Stubborn Debugging) Turned My Terminal Into a Headless Mendix Studio

The itch 🤔

If you’ve used Mendix, you know Studio Pro — the big, friendly visual editor where you click your way to an app. It’s great. But it’s also a window you have to open, a GUI you have to drive by hand.

I had a different idea:

What if my AI assistant could build, check, and run a Mendix app entirely from the command line — and I never had to open Studio Pro at all?

Spoiler: it can. And the journey to get there was equal parts “wow, this actually works” and “why is this build hanging for 39 minutes?” 😅

Grab a coffee — this one’s a ride!

First, a myth to bust 🧨

When people hear “Mendix without Studio Pro,” they assume I’m faking or emulating Mendix. Nope.

Studio Pro is really just a dashboard wrapped around real engines:

• 🖱️ Click in the domain model / pages → the model engine that reads & writes the .mpr
• 🔴 See red error markers → mxbuild / mx check
• ▶️ Hit Run Locally → builds the app + spins up a runtime + a database

My setup just drives those same engines from the terminal — the real mxbuild.exe, the real Mendix runtime. Two steering wheels, one engine.

“It’s not a simulator. It’s the same Mendix machinery — just headless.”

The cast of characters 🎭

To go GUI-free, my AI agent needs four tools working together:

• 🛠️ mxcli — edits the Mendix model from the command line
• 🔎 mxbuild — the error checker (same one Studio Pro uses)
• 🐳 Docker — runs the app + a Postgres database in containers
• 🔬 Chrome DevTools — lets the agent verify the running UI

The problem? Setting all of that up by hand, on a fresh machine, is a chore. So I packaged it.

Enter: mx-studio-automate ✨

One command:

npx mx-studio-automate

It scans your machine, auto-installs the safe stuff, and gives you copy-paste instructions for the heavy stuff (like Docker, which needs admin rights). It even wires up the AI agent’s config so it’s ready immediately.

mx-studio-automate  v0.3.0
✔  mxcli            found   v1.4.0
✔  mxbuild          found   11.10.0
✔  JDK 21           found   21.0.11
✔  Docker           found   29.3.1
✔  Chrome DevTools  found
✔  AI agent config  found
🎉  All set!

Safe to re-run any time — it only ever fills the gaps.

❓ Reader check: How long does setting up a new dev environment usually take you — minutes, or a “clear your afternoon” kind of thing? 👇

The headline trick: build and run, no Studio Pro 🚀

npx mx-studio-automate --run

Behind the scenes it does the whole Mendix deployment dance:

1. Generates a Docker stack (app + Postgres)
2. Builds the app package with mxbuild
3. Boots it all in Docker
4. Hands you a live URL

And because builds can be slow and silent, I added a live loader so you always know it’s alive (and won’t rage-quit mid-build):

⠹  Building app package… 1m 12s — please don't close this window

Then, for the edit→see loop, there’s --reload — a hot reload that pushes your changes into the already-running app in seconds, no cold restart:

npx mx-studio-automate --reload          # rebuild + reload
npx mx-studio-automate --reload --css    # styling only, instant

💡 Tip: After the first --run, you never cold-start again. Edit → --reload → refresh browser. That's the whole loop.

A little terminal eye-candy 🎨

Because if you’re going to stare at a CLI all day, it might as well be pretty. The intro draws itself in — mx as a faint outline, studio in crisp white, automate in Mendix blue:

 _ __ ___ __  __
| '_ ` _ \ \/ /
| | | | | |>  <
|_| |_| |_/_/\_\
    _             _  _
 ___| |_ _   _  __| (_) ___
/ __| __| | | |/ _` | |/ _ \
\__ \ |_| |_| | (_| | | (_) |
|___/\__|\__,_|\__,_|_|\___/
             _                        _
  __ _ _   _| |_ ___  _ __ ___   __ _| |_ ___
 / _` | | | | __/ _ \| '_ ` _ \ / _` | __/ _ \
| (_| | |_| | || (_) | | | | | | (_| | ||  __/
\__,_|\__,_|\__\___/|_| |_| |_|\__,_|\__\___|

🎬 GIF — Record the intro animation (mx → studio → automate revealing top-to-bottom) and drop a short looping GIF here. Tools: ScreenToGif (Windows) / Kap (macOS). Caption: “Yes, I spent an embarrassing amount of time on a terminal banner. Worth it.”

So… should you use it? 🧭

If you’re a Mendix developer who:

• 💻 lives in the terminal,
• 🤖 wants an AI agent to drive your project,
• 🐳 likes running apps in Docker, and
• 🙅 would rather not open a heavy IDE just to check for errors —

…then give it a spin:

npx mx-studio-automate

It’s open source, MIT-licensed, and on npm. ⭐

What I learned 📚

• The “magic” of low-code tools is just real tooling with a nice UI — and you can absolutely reach the tooling directly.
• A good CLI is honest: do the safe magic, but tell the user clearly when they need to act.
• Half of shipping a dev tool is debugging other people’s environments — spaces in paths, stale cookies, version twins, hidden prompts.
• And a little terminal polish goes a long way. 💙

👋 Your turn

Have you ever ditched a GUI for the command line and never looked back? Or is there a tool you wish had a headless mode? Drop it in the responses — I read every one.

If this was useful, a few 👏 claps help more people find it. Thanks for reading!

Read more

• Docker Buildpack
• Reference Guide for Docker Deployment

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Mendix in Docker, One Command🐳 was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

The GenAI Build Gets Serious

A focused guide to the release features that make AI-enabled applications more governable, more connected, and easier to build.

What is GenAI? A quick primer

Generative artificial intelligence, or GenAI, is a class of AI that can create new content or take action from patterns learned in data. It can generate text, summarize documents, classify information, answer questions, create images or code, and support decisions through natural-language interaction.

In a business application, GenAI is most useful when it is connected to the right context and the right action. A model may generate an answer, but the application still needs to provide trusted data, apply access rules, call approved tools, and record what happened. That is why enterprise GenAI is broader than a chatbot: it combines models, knowledge, business logic, user experience, and governance.

A USEFUL MENTAL MODEL:

GenAI supplies the reasoning and content-generation layer. 
Mendix supplies the application model, workflow, data, integrations, 
and controls that turn that capability into a business process.

What GenAI is available in Mendix 11.13.0?

The Mendix GenAI toolbox

Mendix 11.13.0 brings several GenAI capabilities together. Some are platform services, some are development assistants, and some are reusable modules or connectors. The right choice depends on whether you are building an AI-assisted development workflow, a user-facing GenAI feature, or an autonomous agent that can use business tools.

Maia Make:

AI-assisted development in Studio Pro. 
In 11.13, Maia Make can use full expression error details to help 
resolve validation problems and improve iteration quality.

Maia agent skills:

Contextual guidance for selected modules. Skill.md files in GenAI Commons, 
Agent Commons, Conversational UI, and the Mendix Cloud GenAI Connector 
help Maia understand those modules more specifically.

Agent Editor and Agents Kit 2.1:

A foundation for creating and configuring agentic applications, 
including model, knowledge-base, and microflow-tool connections.

Azure AI Foundry support:

A model-provider option in the Agent Editor. 
Teams can select Azure AI and connect agents to text-generation models 
through their existing Azure environment.

GenAI Resource Packs:

A managed way to monitor GenAI consumption. Mendix 11.13 adds Model and 
Key filters across GenAI Units, input and output tokens, and API calls.

GenAI Commons:

Reusable building blocks for GenAI-enabled applications, 
helping teams avoid rebuilding common patterns for every project.

Agent Commons:

Reusable components and patterns for agentic application scenarios, 
including support for agent health validation and 
agent-related capabilities.

Conversational UI:

Reusable user-interface capabilities for conversational experiences,
connecting users to GenAI-backed interactions inside a Mendix application.

Mendix Cloud GenAI Connector:

A connector for integrating Mendix applications with GenAI services and 
using cloud-based GenAI capabilities within application workflows.

Data Importer with Maia:

A native Studio Pro capability that can use an example CSV row to help 
configure import mapping and create the necessary entity structure, 
accelerating data preparation for AI use cases.

At a glance, Mendix makes GenAI more operational

Mendix 11.13.0 is an important step in the platform’s GenAI story because it focuses on the parts of AI adoption that become unavoidable after the first demo: visibility, provider choice, agent health, reusable skills, and dependable developer workflows.

The release adds Model and Key filters to GenAI Resource Pack consumption views, brings Azure AI Foundry into the Agent Editor through Agents Kit 2.1, gives agent teams more support through module-specific Maia skills, and adds health checks that surface missing models, knowledge bases, or microflow tools before an agent version is used in production.

It also improves the surrounding development loop. Maia Make can work with full expression error details, the Data Importer is native in Studio Pro with Maia support, and module updates can preserve local customizations. Together, the features point toward a practical message: GenAI should be built as a governed business capability, not treated as a disconnected experiment.

GenAI operations

AI consumption becomes explainable

The first sign of a mature GenAI platform is not a more impressive prompt. It is a better answer to the question: where did the usage come from? In 11.13, the Consumption page for GenAI Resource Packs adds Model and Key filters.

The filters apply across GenAI Units, input and output tokens, and API calls. A team can select a model to understand its share of consumption, or use a resource key to attribute usage to the application or integration behind it.

Why this changes the operating conversation

Shared AI infrastructure needs shared visibility.

When several apps use the same GenAI Resource Pack, a single total is not enough. The new filters can help teams investigate spikes, compare model usage, prepare internal chargeback views, and make more informed decisions about model selection and budgets.

Practical Starting Point

Create a simple monthly review: top models, top resource keys, total tokens, and unexplained changes. Treat that view as the GenAI equivalent of an application operations dashboard.

Agents Kit 2.1

Agents get a broader model-provider path

Agents Kit 2.1 adds Azure AI Foundry support in the Agent Editor. Teams can select Azure AI as the provider from the Configuration panel and connect an agent to Azure’s text-generation models.

For enterprises with existing Azure infrastructure, this is more than a connector checkbox. It gives AI builders a way to align agent development with an established cloud environment, identity model, procurement path, and internal governance process.

Which model provider should power which business capability?

Avoid treating provider choice as a one-time platform decision. Compare models by task, data sensitivity, latency, cost, and operational ownership. The goal is not to make every agent use the same model; it is to make the choice deliberate and observable.

Maia and agentic applications

AI-assisted development gets more contextual

Mendix 11.13.0 adds Skill.md files to the GenAI Commons, Agent Commons, Conversational UI, and Mendix Cloud GenAI Connector modules. These files enable tailored Maia support so the assistant can better understand and guide users in the context of those modules.

That context matters because generic coding assistance often stops at syntax. In a model-driven platform, useful help needs to understand domain entities, microflows, module conventions, connector responsibilities, and the relationship between the visual model and the runtime behavior.

The developer benefit

Less time translating platform context into prompts.

Module-specific skills can help Maia provide guidance that is closer to the vocabulary and structures developers are already using. The result is not a replacement for architectural judgment; it is a shorter path from a question to a platform-aware answer.

Agent reliability

Unhealthy agents are easier to find before production

11.13 adds a scheduled health check on the agent overview page. It gives developers a clearer view of whether a version intended for production is missing a connected model, knowledge base, or microflow tool.

The check is also used when validating a version as In Use. That creates a useful guardrail at the moment an agent moves toward active use. Instead of discovering a broken association only inside version details or after a user reaches the agent, teams can surface the problem earlier.

• Check every model connection before a version is marked In Use.
• Confirm that the knowledge base expected by the prompt flow is present and reachable.
• Validate microflow tools as part of the agent’s release checklist.
• Decide where an additional health check belongs in your app, such as an After Start Up action.

Production principle

An agent should be treated like a software release with dependencies, validation, and observable health — not like a prompt that happens to be available.

Faster AI-assisted iteration

Maia Make can see the real expression error

Maia Make can now access full expression error details. Instead of working from a vague validation signal, Maia can use the exact issue to help resolve the problem proactively.

That shifts the developer’s attention from debugging mechanics back to business logic. In a visual development environment, this is especially valuable because the generated or edited logic may involve several layers: an expression, an entity relationship, a variable type, and a microflow context.

What to measure

Track time from validation error to successful run.

Teams evaluating the impact of Maia Make should measure more than generation speed. Look at time-to-resolution, number of manual corrections, repeated errors, and whether developers can explain why the final expression works.

Data importer + Maia

Data ingestion becomes part of the GenAI loop

The Data Importer is now fully native within Studio Pro and includes Maia support. A developer can provide Maia with an example row from a CSV file, and Maia can help set up the importer and map the CSV table into the necessary entities.

For GenAI applications, this matters because data preparation is often the step that slows down the journey from an idea to a useful AI experience. Whether the data becomes knowledge, reference content, customer context, or structured business records, a faster import path can improve experimentation without hiding the underlying model decisions.

Important boundary

Use Maia to accelerate mapping, but review entity names, data types, validation rules, ownership, and sensitive fields before loading real business data.

Mendix 11.13.0 treats GenAI as a platform capability

The GenAI story in Mendix 11.13.0 is not only about what an agent can generate. It is about what a team can see, validate, connect, and improve around that agent. Model and Key filters support governance. Azure AI Foundry adds provider flexibility. Tailored Maia skills add context. Health checks add an operational guardrail. Better error details and data import support make the build loop faster.

Teams that adopt these features thoughtfully can move beyond isolated AI demos. They can build agentic applications that fit business processes, use enterprise infrastructure, and remain understandable to the people responsible for running them.

Final thought

The real GenAI advantage is not having an answer. It is having a trustworthy path from question to action, with the controls to know when that path is working.

Top Generative AI Features in Mendix You Should Start Using Today was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Managing Security the right way

Sharing a direct link to a specific record or screen feels like a small convenience feature, until someone asks a genuinely important question: can a user access that link and see something they shouldn't?

This post covers how security actually works for page URLs and deep links in Mendix, the real difference between the two, and one specific gap worth knowing about before relying on either.

What a Page URL and a Deep Link Actually Are

A page URL is a direct, shareable link to a specific page in a Mendix app. You configure it in that page’s own properties, giving the page a custom, readable URL instead of relying purely on in-app navigation. A deep link, now built natively into Mendix as a microflow URL, works similarly but points to a microflow instead of a page, so custom logic can run first and decide what to show before the user lands on a page.

The practical difference

A page URL takes a user straight to a page. A deep link runs a microflow first, which then decides what happens next, whether that is showing a specific page, redirecting somewhere else, or running some logic based on the link’s parameters.

How security works for page URLs and deep links

• Same security system for both: page URLs and deep links (microflow URLs) both go through Mendix’s normal role-based access rules. Neither one is a separate or lesser security path.
• Access is checked on the destination, not the URL: the actual protection lives on the page’s access rules or the microflow’s logic, not on how the link looks or how hard it is to guess.
• Two possible outcomes after the check: a user either has the right role and the page opens normally, or they don’t, and Mendix redirects them to login (for logged-in-only content) or denies access outright.
• Anonymous access works the same way for both: if a page or microflow is deliberately configured to allow anonymous users, both page URLs and deep links will honor that; if it’s not, both will block it.
• A “hidden” link is not a security boundary: an obscure or hard-to-guess URL feels safer, but it provides zero real protection. Anyone with the link who lacks the right role still gets blocked, and anyone with the right role can reach it however they find it.
• Strict page URL checking only covers page URLs: This Studio Pro setting catches security misconfigurations, but it works only for pages with custom URLs. It cannot see or validate deep links because they are resolved at runtime, not known at design time.
• Deep links carry more manual responsibility: since strict checks can’t catch mistakes here, the microflow behind a deep link needs its own access rules to be double-checked manually rather than relying on an automatic warning.
• Review externally shared links specifically: anything sent in an email, embedded in a notification, or otherwise shared outside the app deserves a deliberate access-rule check, since these are the links most likely to end up somewhere unexpected.

Yes, Page URLs Can Be Customized

Page URLs are fully customizable. You are not stuck with a generated, meaningless string.

In the page’s properties, you set the actual URL text yourself. It also supports parameters so that a link can point to a specific record, such as an order or a customer, instead of just the general page.

This makes links genuinely readable and shareable, whether that’s a link emailed to a colleague or embedded in a notification.

Read more

• Page Properties
• Deep Links

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Managing Security for Page URLs and Deep Links in Mendix was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quick Hack Series Part 5

If you’ve ever needed two Mendix apps to talk to each other without tightly coupling them together, Business Events might be exactly what you’re looking for.

Think of it as a mailing list for your apps: one app publishes an event when something important happens, and any number of other apps can subscribe and react, all without a single direct API call between them.

In this guide, we’ll walk through what Business Events are, when to use them, and how to implement a publisher and subscriber in Studio Pro from scratch.

What Are Business Events?

Business events are like a mailing list to share event notifications between apps. The key difference between business events and traditional communication between apps, such as REST or web services, is that there is no direct communication between the apps. An event broker sits in between and handles delivery.

A classic example: one app uploads a payment receipt while another app processes the outgoing payment in the company’s ledger. Or, a customer places an order, and separately, apps handle shipment scheduling, invoicing, and stock reordering, all triggered off the same event, with zero coupling between those apps.

Let's dive into the implementation!

Step 1: Install the Mendix Business Events Module

To work with business events, import the Mendix Business Events service into your app from the Marketplace.

Step 2: Create a Business Event Service (Publisher Side)

In the app that will publish the event:

1. Right-click a module in your app tree.
2. Go to Add other → Business event service → Create a new business event service.
3. Give your service document a clear name (e.gBE_OrderStatusUpdateService).

This opens the Business Event Service document, where you’ll define:

1. General — the Service name and Event name prefix.

2. In Business Event Definitions — click Add to add a new event where the Event name and Description will be there, so other teams/apps know what this service is about. Then Attributes->click Add to define what data the event carries. Keep in mind: changes here later could lead to breaking changes if the entity is already consumed elsewhere by other apps.

3. Other apps can — decide whether other apps can subscribe, publish, or both to this service. Select Publish events and subscribe to events, then click Done to create the event.

Under This business event service implements, Studio Pro shows you two panels side by side — Publish and Subscribe:

• On the Publish side, the LDMScript event maps to a published entity, PBE_LDMScript — this is the object your microflow will fill in and hand off to the Publish Event activity.
• On the Subscribe side, the same LDMScript event maps to a consumed entity, CBE_LDMScript, with an auto-generated handler microflow, HandleBE_LDMS.Note: when the event is received, this auto-generated microflow will be triggered.

It’s entirely possible, as in this example, for one service document to define both a publish and a subscribe side for the same event, which is handy when you want to test the full round trip within a single app before splitting publisher and subscriber across separate apps.

Under the hood, this service document generates an AsyncAPI 2.2.0 contract. A few things worth noting if you ever inspect or hand off the YAML:

• The channel is identified by a generated GUID (e.g., c11743e61aca4bfda14eb1c4b92549f0), with both a publish and subscribe operation defined against it.
• The message payload schema (LDMScriptPayload) is exactly what you defined in the Attributes tab — in this case, just StatusString: string, maxLength 200.
• Every message carries a set of CloudEvents-standard headers (ce_specversion, ce_id, ce_source, ce_type, ce_time, etc.) — this is what lets Business Events interoperate with other CloudEvents-compatible tooling, including the AWS/Azure bridges mentioned later.

Step 3: Publish the Event from a Microflow

Once your service is defined, drop a Publish Event activity into the microflow where the business action happens.

For our LDMScript example, the flow typically looks like this:

1. Create/retrieve a PBE_LDMScript object (this is the published entity Studio Pro generated for you in Step 2).
2. Change Object — set StatusString to whatever status you want to broadcast (e.g., "Script started", "Script completed", "Script failed: timeout").
3. Add the Publish Event activity, passing in the PBE_LDMScript object.

A key benefit here: publishing is part of the same transaction as your other database changes. If your microflow fails and rolls back, the event is not sent — so if your script-handling logic errors out before reaching the Publish Event activity, you don’t end up with a stray “in progress” status floating around with no corresponding real state.

We have successfully created and published a Business Event. Since this is a broad topic, I’ve split this series into three parts:

• Part 1: Creating and Publishing a Business Event (this article)
• Part 2: Setting up the Event Broker in both Mendix Cloud and on-premises environments.
• Part 3: Creating subscribers to consume the published Business Events.

I hope this helps. Give this feature a try and let me know what you think! Drop a comment below and share whether you found this feature useful and worth trying.

Until next time, keep building and keep hacking!

Read more

• Mendix Business Events
• Business Event Services

From the Publisher -

Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.

For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.

Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!

Getting Started with Mendix Business Events Publishing was originally published in Mendix Community on Medium, where people are continuing the conversation by highlighting and responding to this story.