Repository
Information about the PowerShell Universal repository.
The configuration data for PowerShell Universal is primarily stored within the repository. By default, the repository folder can be found in %ProgramData%\UniversalAutomation\Repository
. You can adjust the location of the repository by editing the appsettings.json
file.
The repository contains PowerShell scripts and XML files that are produced when using the PowerShell Universal admin console. The repository folder is also watched for changes so any change made on disk will cause the system to reload the file and reconfigure the platform. When using Git integration, the repository folder is what is synchronized with the git remote.
All configuration cmdlets are part of the Universal module.
What's Stored in the Repository
Files stored in the repository are stored as plain text to allow for easy differencing with source control tools.
Authentication
Apps
Endpoints
Environments
Licenses
Login Pages
Pages
Published Folders
Rate Limits
Roles
Schedules
Scripts
Settings
Tags
Triggers
Vaults
What's Not Stored in the Repository
These entities are stored within the PowerShell Universal database.
App Tokens
Identities
Job History
Editing the Repository
You can edit the repository files directly in the admin console by navigating to Settings \ Files. The editor allows you to create files and folders and edit any file within the repository directory.

You can also edit the repository directly on disk using editors like Visual Studio Code. By default, files are stored in %ProgramData%\UniversalAutomation\Repository
. You will need to toggle the node into VS Code editing mode. The toggle to do so can be found on the home page. Only administrators will see this button and, if Disable Code First Editing is on in Settings \ General, you will not be able to change the edit mode.

Configuration Scripts
Authentication.ps1
This script is responsible for configuring forms authentication. If forms authentication is not being used, this file is ignored.
You can use the Set-PSUAuthentication
cmdlet in this file.
Branding.ps1
This script is responsible for configuring branding settings.
You can use the New-PSUBranding cmdlet in this file.
Dashboards.ps1
This script is responsible for registering PS1 files are apps within the system. Each command contains the meta-data for the app including name, base URL, and environment.
You can use the New-PSUApp
cmdlet in this file.
Endpoints.ps1
This script is responsible for defining all the API endpoints within the PowerShell Universal instance.
You can use the New-PSUEndpoint
cmdlet in this file.
Environments.ps1
This script is responsible for defining all the environments within PowerShell Universal.
You can use the New-PSUEnvironment
cmdlet in this file.
healthChecks.ps1
This script is responsible for defining Health Checks within PowerShell Universal.
You can use the New-PSUHealthCheck
cmdlet in this file.
Licenses.ps1
This script is responsible for defining the license used in PowerShell Universal.
You can use the Set-PSULicense
cmdlet in this file.
Set-PSULicense -Key "<License></License>"
Initialize.ps1
This script runs before any configuration is done within PowerShell Universal. The server is running but none of the services have started. This is useful for install modules or configuring secret vaults before discovery of those resources are started.
Middleware.ps1
Allows for customization of the HTTP requests in PowerShell Universal.
PublishedFolders.ps1
This script is responsible for configuring published folders.
You can use the New-PSUPublishedFolder
cmdlet in this file.
RateLimits.ps1
This script is responsible for configuring rate limits.
You can use the New-PSURateLimit
cmdlet in this file.
Roles.ps1
This script is responsible for configuring roles.
You can use the New-PSURole
cmdlet in this file.
Schedules.ps1
This script is responsible for configuring schedules.
You can use the New-PSUSchedule
cmdlet in this file.
Scripts.ps1
This script contains the meta-data for scripts. Actual scripts can be stored anywhere. The path that is included is relative to the repository. Full path names are also allowed.
You can use the New-PSUScript
cmdlet in this file.
Settings.ps1
This script is responsible for configuring system settings.
You can use the Set-PSUSetting
cmdlet in this file.
Tags.ps1
This script is responsible for configuring tags.
You can use the New-PSUTag
cmdlet in this file.
Triggers.ps1
This script is responsible for configuring triggers.
You can use the New-PSUTrigger
cmdlet in this file.
Variables.ps1
This script is responsible for configuring variables.
You can use the New-PSUVariable
cmdlet in this file.
Vaults.ps1
This script is responsible for configuring vaults.
Templates
Using the Templates folder within the Repository, you can create a selection of item templates for commonly used features in PowerShell Universal. This includes apps, app pages, scripts and endpoints.

PS1 files in the following folders will be provided as templates in the admin console.
Templates \ App
Templates \ AppPage
Templates \ Endpoint
Templates \ Script
.psuignore
The .psuignore
file can be used to exclude certain files or patterns from the file system watcher in PowerShell Universal. This is useful when saving files like logs to the repository directory. The format of the file should be a single regular expression per line. If the regular expression matches a path, the configuration system will ignore it.
logs.*
.git.*
Read-Only Configuration Sections
Read-Only sections allow you to include script in your configuration files that will not be touched by changes in the admin console. This allows you to run additional logic, generate resources dynamically and create classes for use in OpenAPI schemas.
The PSUHeader
region is placed at the top of your script. PSUFooter
is placed at the bottom.
#region PSUHeader
1..100 | ForEach-Object {
New-PSUEndpoint -Url "/endpoint/$_" -Endpoint {
}
}
#endregion
New-PSUEndpoint -Url "/user" -Endpoint {
}
#region PSUFooter
#endregion
Database Resources
You can optionally configure resources to be stored in the database rather than within the configuration repository. These resources will no longer be stored on disk and will be stored directly in the database. This makes them instantly available to allow connected computers in the PSU cluster.
When configured, configuration files for resources will be ignored.
Some resources are not supported. These include:
Apps
Endpoints with paths
Scripts
Modules
To configure a resource for database persistence, you need to setup the App Settings for each class type. Below is an example of storing schedules within the database.
{
"Data": {
"Persistence" : {
"Schedule": "Database",
"ScheduleParameter": "Database"
}
}
}
Last updated
Was this helpful?