Environments and tenants

Overview

MATTR VII is designed to support customers of all sizes with a flexible, secure, and scalable digital trust platform.

At its core, MATTR VII enables multiple customers to operate independently and securely through a concept called multi-tenancy. Each customer operates in its own isolated space (a tenant), ensuring its data, credentials, and configuration remain private and protected.

Depending on operational, compliance, and change management requirements, customers can choose between:

• A Standard Cloud deployment, where infrastructure is securely and efficiently shared.
• A Dedicated Cloud deployment, where an environment is provisioned exclusively for a single customer.

This flexible model allows customers to balance cost efficiency, scalability, regulatory compliance, and operational control without compromising trust.

What is a Tenant?

MATTR VII implements a multi-tenant architecture, where a single logical platform instance serves multiple tenants.

A tenant represents a distinct and isolated instance of MATTR VII within an environment.

Each tenant maintains its own isolated:

• Data: Credentials, presentations, and verification records
• Configuration: Certificates, credential configurations, policies, and governance rules
• Access control: OAuth clients, API keys, and permissions
• Operational state: Activity logs, analytics, and audit trails

Every Platform API request occurs within the context of a specific tenant.

Tenants are fully isolated. No tenant can access another tenant's data, configuration, or credentials. A tenant in one environment cannot interact with or discover tenants in another environment.

Isolation is enforced at both:

• Functional levels: Ensuring strict data and access separation
• Non-functional levels: Supporting request affinity and workload controls

This ensures strong security boundaries while still enabling efficient shared infrastructure.

Shared vs Isolated: What's the Difference?

Understanding what is shared at the environment level versus what is isolated at the tenant level is key to understanding MATTR VII's architecture:

Shared at Environment Level (applies to all tenants in the environment):

• Platform version and software release
• Core features and capabilities
• Infrastructure and compute resources
• API endpoints and service architecture
• Platform-wide configuration settings (e.g. rate limits, logging levels)

Isolated at Tenant Level (unique to each tenant):

• Credentials, Certificates, and cryptographic keys
• Issued credentials and presentation records
• Credential configurations and templates
• Governance policies and verification rules
• OAuth clients and API access controls
• User data and activity logs
• Custom domains and branding

This separation enables MATTR VII to deliver consistent platform functionality and efficient resource utilisation, while maintaining absolute data isolation and security between tenants.

What is an Environment?

An environment is a deployment boundary for MATTR VII.

An environment includes:

• MATTR VII platform services
• The MATTR Portal (one per environment)
• Token endpoints and APIs
• Supporting infrastructure
• One or more tenants

Multiple tenants can exist within a single environment.

All tenants within an environment share:

• Platform version: The same MATTR VII software release
• Feature availability: The same core platform capabilities and features. Feature flags may exist on a tenant or environment level, but the underlying platform functionality is consistent across tenants in the same environment.
• Infrastructure: Compute resources, network architecture, and platform services
• Release schedule: Updates and patches are applied to the environment as a whole

While tenants share certain environment-level characteristics, they remain fully isolated from each other in terms of data, credentials, and tenant-specific configurations. Environments enable customers to separate workloads, manage release promotion, and meet operational requirements. Environments can also be geographically separated to support regional, regulatory, or performance needs.

Deployment Models

MATTR VII supports two primary cloud deployment models: Standard Cloud and Dedicated Cloud.

Standard Cloud

In the Standard Cloud model, customers receive a tenant in one of MATTR’s shared environments (deployed in a specific AWS region). Each environment hosts multiple tenants, with shared underlying infrastructure.

Available regions currently include:

• US West (Oregon)
• Canada (Central)
• Europe (Frankfurt)
• Asia Pacific (Singapore)
• Asia Pacific (Sydney)
• Asia Pacific (New Zealand)

What is Shared?

• Underlying infrastructure
• Compute resources
• Platform services

What is Isolated?

• Tenant data
• Credentials
• Configuration
• Access control policies
• Governance rules

All tenants receive the same core MATTR VII product functionality within the environment. Feature flags and configuration may influence what is enabled for a particular tenant.

Dedicated Cloud

Dedicated Cloud is MATTR’s solution for customers who require a dedicated environment and/or customer-approved and coordinated change management.

Dedicated Cloud includes:

• One or more environments deployed in any AWS region
• All customer data isolated within an individual AWS account that is not shared with other customers
• Compute resources allocated to the Dedicated Cloud environment and shared only across that customer’s tenants

Within each environment:

• Multiple tenants can be created
• Tenants remain fully isolated from one another
• MATTR VII and MATTR Portal are deployed and released into that environment

Dedicated Cloud includes enhanced operational controls such as:

• Configurable platform event logging levels
• Integration with customer SIEM solutions

These capabilities provide improved visibility and alignment with enterprise security monitoring requirements.

Isolating deployment stages

Most organisations need to separate their development, testing, and production workloads to reduce risk and manage changes safely. How you achieve this depends on your deployment model.

Standard Cloud

Standard Cloud customers operate within a single shared environment and cannot provision separate environments. Instead, use separate tenants to represent each stage of your software development lifecycle.

A common pattern is to use distinct tenants for:

• Development
• QA / testing
• Staging
• Production

At a minimum, it is recommended to keep non-production and production workloads in separate tenants. Because each tenant is fully isolated — with its own credentials, configurations, access controls, and data — changes made in a development or staging tenant cannot affect your production tenant. Teams can maintain separate API client credentials and access controls per stage, and safely validate credential configurations and policies before promoting them.

Note that all tenants within a Standard Cloud environment share the same platform version and release schedule. If your organisation requires independent release management or coordinated change control across stages, consider Dedicated Cloud.

Dedicated Cloud

Dedicated Cloud supports provisioning multiple environments within a single customer account, enabling a traditional model of promoting changes progressively across distinct stages — for example, Development, QA, Staging, and Production.

Each environment operates independently and can run at a different software version, giving teams full control over when platform updates are adopted at each stage. Changes validated in a lower environment can be promoted to the next, reducing risk before they reach production.

Custom Domains

Custom domains in MATTR VII allow organisations to present a trusted, branded experience to end-users, while maintaining secure and structured platform architecture.

Custom domains can be applied at two levels:

• Per Tenant (Custom Domain)
• Per Environment (Environment Domain, Dedicated Cloud only)

These serve different purposes and operate differently.

Tenant-Level Custom Domains

A tenant-level custom domain allows you to represent your brand when interacting with end-users.

For example, an end-user may hesitate to claim a credential issued from a MATTR VII tenant URL such as https://learn.vii.au01.mattr.global, because the end-user may not recognise MATTR as the issuing authority.

By configuring a custom domain (for example, https://credentials.yourorganisation.com), you can:

• Reinforce brand recognition
• Increase user confidence
• Provide a seamless, trusted experience
• Align credential flows with your organisation’s identity

Refer to our Custom Domain Overview for more details on tenant-level custom domains.

Environment-Level Domains

Environment-level domains apply to the entire environment, not to an individual tenant. This configuration is typically used in dedicated cloud deployments.

When applied at the environment level, a domain can be configured for:

• The MATTR VII base API endpoint
• The OAuth token endpoint
• MATTR Portal
• DTS (Digital Trust Service) website

Unlike tenant-level custom domains, environment-level domains are part of the infrastructure and deployment configuration, rather than a branding mechanism for a specific tenant.