Environment management

An environment on GLBNXT Platform is the complete, isolated deployment of the platform stack allocated to your organisation or to a specific project, team, or client. It contains your compute resources, deployed services, model endpoints, data stores, access controls, and audit trail. Everything your team builds and operates on the platform lives within the boundary of your environment.

Managing your environment well means understanding how it is structured, how to keep it aligned with your team's evolving needs, and how to operate multiple environments effectively when your delivery model requires it. This section covers the structure of GLBNXT Platform environments, how to manage environment configuration over time, and the patterns for organising environments across development, staging, and production workloads.

Environment Structure

Every GLBNXT Platform environment is a dedicated, isolated deployment. At the infrastructure level, your environment has its own compute allocation, network boundary, storage instances, and Kubernetes namespace. No infrastructure resources are shared with other environments or other organisations. Isolation is enforced at the platform layer, not just through access controls.

Within your environment, the components deployed during onboarding form the baseline stack. This includes the model endpoints available in your Model Hub, the data services provisioned for your use cases, the workflow automation tools available to your team, and the frontend components configured for your applications. The specific composition of your stack reflects the requirements agreed during onboarding.

Your environment has its own access control configuration, with user accounts, roles, and service accounts managed independently of any other environment. Audit logs and query history are scoped to your environment. There is no cross-environment visibility of activity, data, or configuration.

Environment Configuration

Environment configuration covers the settings, parameters, and policies that determine how your environment behaves. Configuration is established during onboarding and can be updated over time as your requirements evolve.

Key areas of environment configuration include the following.

Compute allocation defines the GPU and CPU resources available for workloads in your environment. The initial allocation is agreed during onboarding based on your anticipated workload. As your applications grow and usage increases, compute allocation can be reviewed and adjusted through your GLBNXT contact. Monitoring compute utilisation through the Observability and Monitoring area of the platform console gives your team the visibility needed to identify when allocation adjustments are appropriate.

Model configuration defines which models are deployed in your Model Hub, the serving runtime applied to each, and the endpoint configuration your applications use to access them. Model configuration changes, including adding new models, updating model versions, or removing models that are no longer needed, are managed through your GLBNXT contact following the model governance process described in the Model Evaluation and Versioning section.

Data service configuration covers the storage instances provisioned in your environment, including database sizes, object storage capacity, and vector database collection configuration. Data service configuration should be reviewed as your data volumes grow to ensure that storage capacity and performance remain appropriate for your workloads.

Security and access configuration covers identity provider integration, role definitions, MFA policies, and network access rules for your environment. Changes to security configuration should be treated as controlled changes and reviewed against your security requirements before being applied.

Compliance configuration covers audit log retention periods, data retention policies, and any compliance-specific settings applied to your environment. Compliance configuration changes should be reviewed against your regulatory obligations before being applied and documented for audit purposes.

Development, Staging, and Production Environments

For organisations building production AI applications on GLBNXT Platform, a multi-environment model separates development and testing activity from production workloads. The standard pattern uses three environments.

Development Environment

The development environment is where your team builds, experiments, and iterates. It is configured to support active development work with access to the platform components needed to build your solutions. The development environment does not need to mirror the production environment exactly in terms of compute allocation or data volumes. It is optimised for development velocity rather than production reliability.

In the development environment, your team can build and test new solutions, try different model configurations and prompt designs, experiment with retrieval and pipeline architectures, and iterate rapidly without risk of affecting production workloads or production data.

Data used in the development environment should be representative of production data in structure and format but should not be actual production data containing personal information or sensitive organisational content unless appropriate data protection measures are in place. Using synthetic or anonymised data in development reduces the risk of accidental exposure and simplifies compliance with data minimisation obligations.

Staging Environment

The staging environment is a pre-production environment that mirrors the production environment as closely as possible in terms of configuration, compute allocation, and data setup. It is used to validate that a solution behaves correctly in a production-equivalent environment before it is promoted to production.

Testing in staging should cover functional validation of the solution against real or production-representative data, performance testing under realistic load conditions, security and access control validation, and compliance review of audit logging and data handling behaviour. Issues identified in staging are resolved before promotion to production, not after.

Maintaining parity between staging and production environments requires discipline. Configuration drift, where staging and production diverge over time due to changes applied to one but not the other, reduces the reliability of staging as a pre-production validation environment. Changes to production configuration should be validated in staging first, and changes applied to staging should be applied to production promptly rather than allowed to accumulate as unreviewed differences.

Production Environment

The production environment runs live workloads serving real users and real processes. It is configured for reliability, performance, and compliance rather than development convenience. Access to the production environment is more tightly controlled than in development and staging, with role assignments reflecting the distinction between building solutions and operating them.

Changes to production workloads, model configurations, data services, and environment settings are managed as controlled changes. No change should be applied to production that has not been tested in staging. Unplanned changes to production environments are a common source of incidents in AI application deployments and should be prevented through clear change management processes, not just good intentions.

Environment Lifecycle Management

Provisioning New Environments

New environments are provisioned by GLBNXT in collaboration with your team. The provisioning process follows the same onboarding steps described in the Onboarding Overview section, with the stack, compute allocation, model selection, and compliance configuration agreed before the environment is made available.

For organisations operating a multi-environment model, new environments can be provisioned to match an existing environment's configuration as a baseline, reducing the setup effort for staging and development environments that are intended to reflect a production configuration.

Updating Environment Configuration

Requests to update environment configuration are submitted to your GLBNXT contact. Configuration changes are reviewed, validated, and applied during an agreed maintenance window or, for urgent changes, through an expedited process with appropriate review.

Your team should maintain a record of environment configuration decisions and changes, documenting what was changed, why, and when. This record supports troubleshooting when unexpected behaviour follows a configuration change, and provides the change history needed to support audit and compliance requirements.

Decommissioning Environments

When an environment is no longer required, decommissioning should follow a defined process to ensure that data is handled correctly, access is revoked, and resources are released. The decommissioning process includes exporting or confirming deletion of any data that must be retained for compliance purposes, revoking all user accounts and service accounts associated with the environment, confirming that any dependent systems or integrations are updated to remove references to the decommissioned environment, and notifying GLBNXT to release the infrastructure resources allocated to the environment.

For client environments being decommissioned at the end of a partner deployment, data deletion should be confirmed in writing and documented as evidence that data has been handled in accordance with the applicable data processing agreement.

Environment Observability

The operational health of your environment is visible through the Monitoring and Observability area of the platform console. Infrastructure metrics, service availability, compute utilisation, and audit activity are all scoped to your specific environment, giving your team the visibility needed to manage the environment effectively without access to broader platform infrastructure.

For teams operating multiple environments, observability data is maintained separately in each environment. Your team has visibility into the environments they are authorised to access based on their role assignments. Cross-environment reporting, such as aggregated usage data across development, staging, and production, is available through your GLBNXT contact for environments within the same account.

For guidance on the access control configuration that governs who can view and modify environment settings, see the Access Control and Identity section. For guidance on the monitoring and observability capabilities available within your environment, see the Observability and Monitoring section.