Deploy anywhere

Run Maintra on the infrastructure your operation already trusts.

Maintra ships as a containerized API application backed by a database. Run it on a private VPS, on-premise infrastructure, AWS, Google Cloud or another container platform, then size each environment for its workload and service levels.

Plan a technical review
  • Google Cloud
  • Private VPS
  • On-premise
Three standard enterprise server racks with application, network, database and storage hardware plus visible spare capacity
The same container can run on AWS, Google Cloud, a private VPS or on-premise; application and database capacity are sized separately.

Reference topology

The same container, sized for each environment.

Development can share a compact node. UAT adds separation and recovery controls. Production adds replicas and database resilience to meet agreed service levels.

Runtime configuration

Move between infrastructure providers without changing application behaviour.

Runtime configuration supplies the database, allowed origins, identity provider, secrets and operating settings. The API container can run on AWS, Google Cloud, a private VPS or on-premise infrastructure. Managed services remain deployment choices.

  • Self-managed or managed database
  • VPS, private data centre or cloud container platform
  • S3-compatible object storage where attachments require it

Environment design

Give each environment the controls its risk requires.

Development can use a compact topology. Test and UAT add controlled data, identity and promotion. Production adds the backup, observability, TLS, recovery and availability controls agreed for the operation.

  • Environment-specific secrets and configuration
  • Alembic-managed database schema evolution
  • Reviewed promotion with environment-specific migration controls

Horizontal scale

Add API and worker capacity after measuring demand.

API containers can run behind a load balancer because the database stores durable business state. External workers add background capacity through leased, fenced job claims that can recover after interruption.

  • Independent API and worker replica counts
  • Connection-pool budgets aligned with database capacity
  • Lease renewal, retry and abandoned-claim recovery for durable work

Service levels

Set availability and recovery targets from operational risk.

Technical discovery defines the production topology. Traffic, site criticality, maintenance windows, data residency, backup requirements and recovery objectives determine the required controls.

  • Load balancing, health checks and controlled rollout
  • Backup, restore rehearsal and migration verification
  • Deployment-specific observability and incident runbooks

Implementation constraint

Specify and test service levels for each deployment.

Availability and throughput depend on the deployed topology. Each proposal defines that topology, its recovery objectives and the representative load tests required for production acceptance.

Related decisions

Continue the technical review.

Architecture overview
API as the product

One EAM API for every client.

 Data & scale

Keep transactions in the database. Add caches for measured bottlenecks.

 Custom apps & connections

Use Maintra apps or build a custom client against the same APIs.

 Agent-assisted delivery

Use delivery agents for bounded changes under human release control.

Evaluate Maintra against a real maintenance process.

Use a representative asset, work order, access model and operational handoff to assess product fit.

Plan an evaluation session