Roles and permissions

Windmill provides a roles and permissions system that allows you to control access and manage permissions within your instance and workspaces. Different roles have different levels of access to scripts, flows, apps, and other entities in Windmill.

Everybody having access to a Windmill instance is considered a User.

Recap of how roles within an instance and a workspace are structured:

Recap Instances and Members

Recap of how are permissioned items (scripts, flows, apps, resources, variables, schedules, jobs) within a workspace:

Recap Item Permissions

Users

Users are uniquely identified globally by their email. They also have a unique username with respect to each workspace they are member of.

Workspace

Every nameable or pathable entity in Windmill has a workspace attached to it. This includes:

users
groups
scripts
resources
variables
schedules
jobs

Windmill's entire database is partitioned by workspaces such that users, teams and orgs can safely co-locate without risk of leakage.

Any user can create their own workspace. When a user creates a workspace, the user is an admin of such workspace and he can invite others to join his workspace.

Roles in Windmill

Users can be given different levels of permissions:

Superadmin

The superadmin role has the highest level of access and can manage the entire Windmill instance. Only superadmins can access the dedicated 'admins' workspace. Also by default, superadmins have access to all workspaces as admins of those workspaces. When an admin does an action as a user of a workspace he is not a member of and as such as no username in, their email is used in lieu of the username. Windmill can be configured to remove the ability for non-superadmins to create workspace using the: CREATE_WORKSPACE_REQUIRE_SUPERADMIN env variable.

Admin

At the workspace level, admins have the ability to manage a specific Windmill workspace and users within that workspace. They can see and edit all scripts, flows, apps, and other entities within the workspace. Admins have the power to create, modify, and delete entities and can manage permissions within the workspace.

At the folder level, an admin of a folder has read, write and archive access to all the elements inside the folders (scripts, flows, apps, resources, schedules) and can manage the permissions as well as add new admins.

Developer

Developers can execute and view scripts, flows, and apps within a workspace. Developers see the full interface of Windmill and contrary to the Operators, they have the ability to create and edit scripts, flows and apps. Developers have read and write access to the entities they create or have been granted access to by others.

Operator

Operators have limited access within a workspace. They can only execute and view scripts, flows, and apps that they have visibility on, and only those that are within their allowed path or folders. Operators do not have the ability to create or modify entities. The recommended way to share scripts and flows with operators is through auto-generated apps. With the second option being of sharing the script and variables it depends on (but operators won't be able to load variable directly from the UI/api, only use them within the scripts they have access to).

Anonymous app viewers

Anonymous app viewers are individuals who can access and view Windmill apps without being a user but by knowing the secret URL that allows app viewing. They do not have any editing or privileges to execute scripts and flows. The apps that they see execute the scripts and flows that are part of the app but only on behalf of the app author. The anonymous user cannot execute any of the scripts and flows part of the apps outside of the inputs authorized by the app through a policy that is automatically generated by the app.

Groups and folders

Groups classify users with shared permissions, while folders group items and assign role-based access control.

Publish Publicly (App editor)

The app can be accessed by anyone who knows the secret URL.

Permissions and Access Control

Windmill implements a fine-grained Access Control List (ACL) by default, allowing you to define permissions for various entities within the system, including:

There are 3 possible roles for each item:

Admin (Owner): has read, write and archive access. Admins of an item can't delete it unless they are admins of the workspace.
Writer: has read, write and archive access. They can't archive nor change the path of the item.
Viewer: has read-only access to the item.

Admins of a workspace have elevated privileges and can read and write over everything within the workspace, disregarding ACLs.

The ACLs are defined by the path of the item.

Path

Windmill uniquely identifies scripts, variables, resources, schedules - and in general almost everything - using their path. The paths are globally unique within the category of entities they represent. In short, a Resource and a Schedule for example can have the same path, without conflict.

Each entity's ACL defines its owner and specifies the read and write permissions. By default, only the owner of an entity has read and write access to it. Entities can be explicitly shared with other groups and users in either read-only or read and write mode through folders. Write mode implicitly includes read permission.

A path is either inside a user space u/<user>/<path> or inside a folder f/<folder>/<path>. The path defines permissions with:

a User: that user will be by default given read, write and archive access on the item (u/henri/amazed_postgresql).
a Folder: the item will be available to the users having access to the folder, with its own levels of permissions (f/data_team/amazed_postgresql).