Appearance
Deployment and integration overview
NOOSAdmin is a self-hosted TypeScript platform intended for cloud, hybrid and on-premises architectures. It provides an application layer around project data, models and independent components, with user access and presentation configured for the project's purpose.
This page describes its place in a system and the decisions that inform a deployment. Installation commands, infrastructure sizing and operational procedures require deployment-specific technical detail.
Deployment contexts
Self-hosting places the platform within an infrastructure arrangement selected for the project. The appropriate context depends on where data and connected services reside and how the application will be operated.
| Context | General meaning |
|---|---|
| Cloud | The application operates using cloud-hosted infrastructure. |
| On-premises | The application operates within infrastructure maintained at the organisation's premises. |
| Hybrid | The overall system combines infrastructure across environments, such as on-premises and cloud services. |
These describe deployment contexts, not predefined installation packages. A specific arrangement needs to establish component locations, connectivity and the responsibilities of the teams operating it.
Connecting data, models and services
The platform's integration approach brings together three broad inputs: project data, computational models and independent services or applications.
Data ingress provides mechanisms to receive or retrieve external information. Processors provide TypeScript logic over application records. Runners integrate Docker-packaged computation with defined inputs and outputs. Explorers, dashboards and portals present information and actions to users.
The integration work establishes the agreements between those parts: what data is exchanged, what starts an operation and how a result becomes meaningful application information. The specialist logic remains in the relevant script, model or component.
Application and data responsibilities
NOOSAdmin follows the application's data model and can work with existing databases. It can also use a separate database for application data from the database holding its operational data.
This makes data location an early deployment consideration. Identify the records the application manages, the systems that supply them and the storage arrangement they require. The listed database options and relational modelling concepts are covered in Databases and data modelling.
Access planning is another part of the application arrangement. Organisations, roles and user groups establish responsibilities and permissions within NOOSAdmin. The platform description also includes authentication and identity-provider integration; the provider and configuration details depend on the deployment.
Growing a deployment
The platform overview describes progression from a focused application to a connected and distributed system, with components able to scale independently.
| Deployment shape | Components described in the platform overview |
|---|---|
| Focused deployment | Application, data and one module. |
| Connected platform | Multiple sources, models and workers. |
| Distributed operation | Scaled services, queues and object storage. |
These are architectural illustrations. They do not define automatic transitions, required service counts or capacity guarantees. A project's growth may involve more data sources, more users or additional computation, and the infrastructure arrangement must account for the particular workload.
The practical planning question is which parts of the system will face increased demand. Data retrieval, storage, computation and user-facing access can have different operating requirements. The implementation determines the appropriate configuration and scaling approach for each.
Optional NOOSChain integration
NOOSAdmin can connect with NOOSChain where independent verification is useful. The stated purpose is to anchor selected platform events, data or model results in a shared, verifiable history.
In this arrangement, NOOSAdmin supplies the application experience and NOOSChain supplies the verification role. Verification is an optional integration whose relevance depends on the project.
A team considering it should identify what outcome needs verification and who needs to verify it. The exact information recorded, verification method and integration configuration require further technical specification. The overview does not establish that all application data is recorded through NOOSChain or that verification confirms the correctness of a model's reasoning.
Planning the deployment
The following questions help describe the intended system before implementation:
| Question | Decision it informs |
|---|---|
| Where does project data reside? | Database connections and data collection arrangements. |
| Which external components must participate? | Ingress, runner and service integration requirements. |
| What initiates collection and computation? | The relevant recurring rules, triggers and user actions. |
| Who uses and administers the application? | Organisations, roles, groups and portal audiences. |
| Where should results be stored and presented? | Result tables, queries, dashboards and pages. |
| Who operates each component? | Responsibilities for the platform and its connected infrastructure. |
| Does a specific outcome need independent verification? | Whether to scope optional NOOSChain integration. |
A clear deployment description connects these decisions to the application's purpose. It gives the implementation team a shared account of the data, computation, audiences and infrastructure involved.