Locally Teams

Locally Policies

Locally Policies lets team admins share custom Azure Policy definitions with the team, so everyone can see which of their resources don't comply in the Locally Dashboard, under Governance → My Team's Policies.

Team admins add a policy in your Locally Account by pasting in its JSON definition. Policies are evaluated in Audit mode against the Subscription you've selected in the Dashboard - so they flag resources that don't comply without blocking a deployment. That way you (or your agent) can iterate freely, and then determine what needs bringing into line - either as you go, or at the end. Any parameters use their default values.

For example:

• Tagging conventions - require every resource to have a cost-center, owner or environment tag, and spot anything that doesn't before it reaches Azure.
• Regions and SKUs - flag resources in regions your team doesn't use, or Premium SKUs you wouldn't use for development.
• Security baselines - require TLS 1.2 or later, public network access to be disabled or customer-managed keys - the same rules you already enforce in production.
• Trying out a new rule - since nothing's blocked, you can see which resources a new rule would flag before enforcing it in Azure.

Learn more about Policy & Compliance →

Locally Runbooks

Locally Runbooks provision the infrastructure and data your team depends on - using ARM Templates, SQL scripts for MySQL and PostgreSQL, and users, groups and service principals in the Directory Emulator.

Runbooks with Auto-deploy enabled are deployed every time Locally starts, in the order team admins have set - and the rest can be deployed when you need them, using the Locally CLI, the Locally Dashboard or the MCP Server. For example:

• Core networking - auto-deploy your Virtual Network and subnets, so everyone's environment has the same shape as production.
• Shared infrastructure - the Service Bus namespace or Key Vault the rest of your apps depend on, set up the same way for everyone.
• Seed data - create a PostgreSQL Flexible Server, then load the schema and data your integration tests expect.
• Identities - the users, groups and service principals your application expects to find in the directory.
• Optional extras - resources only part of the team needs, deployed with a single command when you need them.

Learn more about Locally Runbooks →

Locally Directory

Locally Directory is a source of knowledge for your team - showing who's been working with each Azure service recently, based on what they've deployed to Locally, so you know who to ask.

It's built from the analytics each team member chooses whether to share, and covers the last 90 days - weighting recent activity more heavily.

Team admins choose whether it's enabled when creating the team (it's on by default), and can turn it on or off at any time from the team's Settings page in your Locally Account. If your team belongs to an organisation, this is controlled by the organisation instead.

For example:

• Finding a reviewer - for a change to a service you don't normally work with.
• Onboarding - for someone new, "ask whoever's been working with Key Vault lately" beats "ask around".
• Spreading knowledge - if only one person has worked with Front Door lately, that's a good chance to pair up.

Learn more about Locally Directory →

Team management

Your team is managed in your Locally Account, which also includes:

• Members - invite colleagues with an invite link, and choose whether each one is an Admin or a Member. Admins manage what's shared with the team, and its settings. If your team is synced from your organisation's identity provider, its members are managed there instead.
• Team CI (OIDC) - OIDC trusts which let your CI/CD pipelines, such as GitHub Actions or GitLab CI, run Locally on behalf of your team - without storing long-lived credentials.
• Overview - how many team members are active, and the resources and resource types they've provisioned in the last 30 days.

How sync works

Each Locally install pulls its team content from your Locally Account on a schedule, with manual refresh available from the dashboard. Content is cached locally, so day-to-day work doesn't depend on a live connection - the next time the installation can reach your Locally Account, it picks up any changes admins have made.

Should you encounter any issues, please take a look at the troubleshooting section.