Windmill Resources

Resources store credentials and configuration for external services.

File Format

Resource files use the pattern: {path}.resource.json

Example: f/databases/postgres_prod.resource.json

Resource Structure

{
  "value": {
    "host": "db.example.com",
    "port": 5432,
    "user": "admin",
    "password": "$var:g/all/db_password",
    "dbname": "production"
  },
  "description": "Production PostgreSQL database",
  "resource_type": "postgresql"
}

Required Fields

• value - Object containing the resource configuration
• resource_type - Name of the resource type (e.g., "postgresql", "slack")

Agents

An agent, as the Agents page lists it, is a resource of type ai_agent. Its value holds the agent's provider, system prompt, tools and memory settings, and a flow step uses a saved agent by linking its path. Before writing one, use the agents skill.

Variable References

Reference variables in resource values:

{
  "value": {
    "api_key": "$var:g/all/api_key",
    "secret": "$var:u/admin/secret"
  }
}

Reference formats:

• $var:g/all/name - Global variable
• $var:u/username/name - User variable
• $var:f/folder/name - Folder variable

Secrets

Never put a secret (password, API key, token) inline in a resource value. Store it in a secret variable and reference that variable as $var:<path>.

• $var:<path> is a reference, not a value: it resolves to the variable's value at run time. Never invent a value for a variable.
• A resource that references a variable needs the variable to exist first, so create or deploy the variable before the resource.
• A secret's plaintext never goes in a file of the repo: a .variable.yaml holding it would be committed. Ask the user to create the secret on the workspace instead, e.g. wmill variable add '<value>' <path> (a secret by default), then reference it by path.

Resource References

Reference other resources: