// docs / projects
Projects
A project is the unit of access in Openflow. Instances belong to projects; users get to instances by being members of the project that owns them.
The model
Every user gets a default personal project at first login. Most teams quickly create
shared projects to group instances by domain (integrations,
experiments, customer-x) and invite their colleagues.
A project owns three things:
- A member list: who can see and operate its instances.
- A set of instances: the Node-RED runtimes themselves.
- An MQTT topic namespace: the broker mountpoint
openflow/<projectId>/, used to isolate broker traffic between tenants.
Roles
Two roles, deliberately few.
| role | can |
|---|---|
owner | everything a member can, plus: add/remove members, rename the project, delete the project, transfer ownership |
member | create, start, stop, edit, delete instances; launch the editor; manage backups and snapshots; configure MQTT |
The platform also has a super admin role at the user level, set on
users.is_super_admin. Super admins can inspect any project and any instance
regardless of membership. The bit is set through the database directly or through the
admin tab if you're already an admin.
Invitations
To add someone to a project, click Invite from the project page and enter their email. The invitation is delivered to their in-product inbox (a generic per-user inbox for platform notifications). They accept it from there and they're in.
If the email doesn't match a registered user, the invitation waits until they sign up. Once they register with that email, the inbox item is waiting for them.
Moving instances between projects
From the instance's Danger Zone tab, pick the destination project from the dropdown and confirm. Authorization requires that you're a member of both projects (the source and the target). Platform admins can move any instance into any project.
operational note Moving an instance changes its MQTT topic mountpoint (the prefix becomesopenflow/<newProjectId>/). The new prefix is only applied when the container is next created, not on the move itself. The Danger Zone shows Restart needed after a successful move; restart the instance so the newOPENFLOW_MQTT_TOPIC_PREFIXenv var takes effect.
The MQTT boundary
Two instances in the same project share an MQTT namespace and can subscribe to each other's topics directly. Two instances in different projects cannot, even if they publish to identical-looking topic strings, because EMQX silently prefixes both sides with the project mountpoint.
If you want two instances to exchange MQTT messages, put them in the same project. If you want them isolated, put them in different projects. That's the only knob.