Staging the tenant: account, environments and access posture
Whose cloud account the deployment runs in, the separate vault tenant, which environments exist in which year, and whether the tenant is reachable from the public internet or only privately.
People say "private tenant" and "public tenant" and mean three different things. In TRANXACT Private Cloud they separate cleanly into three decisions, and it is worth using these words for them:
| Decision | Options | Decided |
|---|---|---|
| Isolation — is anything shared with another customer? | No. Every deployment is single-tenant: a dedicated VPC/VNet, cluster and database per customer, and no shared ledger or database. | Not a choice; always so. |
| Account ownership — whose cloud account is it? | TRANXACT-hosted: a dedicated account or subscription TRANXACT provides. Customer-owned: the customer’s own account, which TRANXACT operates through a delegated automation role. | Before signing; written into the contract annex. |
| Access posture — how is it reached? | Public: users reach it over HTTPS on the internet (the default). Private-only: the public listener is closed and it is reached only over VPN, private connection or peering. | Before signing, with the connectivity option. |
There is no multi-tenant, shared "public tenant" edition of TRANXACT Private Cloud. When a customer says public tenant they almost always mean a deployment reachable from the internet — which is the default posture of a dedicated tenant, not a different product.
Account ownership
| TRANXACT-hosted | Customer-owned | |
|---|---|---|
| Who creates the account | TRANXACT (INFRA_2.1.01) | The customer: creates it, sets up billing, applies landing-zone policies and grants the TRANXACT automation role (INFRA_2.1.02, Excluded) |
| Who pays the cloud bill | Per the order form | The customer, billed directly by the provider at its list rates |
| Reserved capacity | TRANXACT recommends (INFRA_2.1.05) | TRANXACT recommends; the customer purchases (INFRA_2.1.06, Excluded) |
| Guardrails, tagging, budget alerts | TRANXACT (INFRA_2.1.04) | TRANXACT applies them inside the customer’s landing-zone policies |
| RACI | Customer A/R for account, landing zone and billing in both cases; TRANXACT consulted |
Either way, TRANXACT also provisions a separate vault account or tenant with its own identities, MFA and keys (INFRA_2.1.03). It is the one piece that is never in the same account as production — see Availability, Live DR, backup and the vault.
Reserved capacity typically cuts compute cost 30–40%. On a customer-owned account it is the customer who buys it, so put the recommendation in front of finance, not only IT.
Environments
An environment is one isolated TRANXACT instance — production, test/QA, training or sandbox. The usage tier includes a number of them:
| Tier | Environments included |
|---|---|
| S | Production + 1 non-production |
| M | Production + 2 non-production |
| L | Production + 3 non-production |
| XL | Per landscape |
- Non-production databases run without an HA standby.
- Live DR adds a full-size copy of the production row, in the second region.
- More non-production environments are Optional (TO_4.1.04), sized per usage tier.
- A migration environment for year 1 is Optional (MIG_8.1.03) and is decommissioned after cutover (TO_4.1.05, a Standard service request).
- Non-production availability is 95%, measured monthly.
A landscape by contract year (example, tier M)
| Environment | Purpose | Nodes | Managed DB | Year 1 | Years 2–5 |
|---|---|---|---|---|---|
| PRD | Production | 3 × 8 vCPU / 32 GB | 8 vCPU / 64 GB HA, 1 TB | Yes | Yes |
| DR | Live DR of PRD | 3 × 8 vCPU / 32 GB | Replica, 1 TB | Yes | Yes |
| QAS | Test / regression | 3 × 4 vCPU / 16 GB | 4 vCPU / 32 GB, 1 TB | Yes | Yes |
| TRN | Training / sandbox | Shared with QAS | 2 vCPU / 16 GB, 500 GB | Yes | Yes, scaled down |
| MIG | Migration trial loads | 3 × 8 vCPU / 32 GB | 8 vCPU / 64 GB, 1 TB | Yes | No — decommissioned |
| Vault | Air-gapped backups | — | Storage only | Yes | Yes |
Plan year 1 with the extra migration and training capacity it needs, then step down. Each change is a change request, so write the step-down into the proposal now rather than negotiating it in year 2.
Staging order
- Agree account ownership, region and Live DR region before signature. Region, address ranges, FQDN and database engine cannot change after the build starts without a rebuild and a change request.
- If customer-owned: the customer creates the account, applies its landing-zone policies and grants the automation role — in parallel with contracting.
- TRANXACT provisions the vault account, applies guardrails, tagging and budget alerts.
- Build the network per region: a dedicated VPC/VNet with its subnets (see Network topologies).
- Build environments from infrastructure-as-code (TO_4.1.01): the cluster, the HA database, object storage, and the Live DR region if contracted.
- Copy infrastructure-as-code and configuration to the vault (TO_4.1.06). The runtime is rebuilt, not restored.
- Send credentials to the named technical contact only (TO_4.1.02); the customer verifies connectivity and SSO (TO_4.1.03).
Access posture
| Public (default) | Private-only | |
|---|---|---|
| How users arrive | Public DNS → global traffic manager → load balancer + WAF over TLS 1.2+ | Customer DNS private zone → VPN / private link → internal load balancer |
| What it needs | An FQDN, a public DNS record, a public-CA certificate | All of that, plus private connectivity, a private DNS zone or conditional forwarding |
| Narrowing it | Optional IP allow-listing on the public listener (INFRA_2.6.04, Standard) | The public listener closed (INFRA_2.6.05, Optional) |
| Remote users | Straight in, SSO and MFA through the customer IdP | Need VPN or zero-trust access to the private path |
| Time to go live | Fastest — no network build | Longer — address planning, routing, firewall and DNS work on the critical path |
Decide early whether HTTPS-only access is enough. Private connectivity adds work that sits on the critical path to go-live, and private-connection circuits often take weeks to order from the carrier.
Values marked proposed default are the deployment guide’s recommended starting points. Confirm each one per customer; the contract, order form, SLA and DPA prevail over this page.