Self-Hosted Zero Trust Network Access

Run your access platform in infrastructure operated by your organization or MSP.

ZTXGate provides Zero Trust Network Access without requiring a mandatory CoreZT-hosted cloud control plane for core access operation. Deploy it on-premises, in a cloud VM, across hybrid infrastructure, or inside an isolated environment.

What Self-Hosted ZTNA Means​

For ZTXGate, self-hosted means the software runs inside infrastructure operated by the customer or by an MSP acting on the customer’s behalf.

The deployment operator determines where ZTXGate runs, how the host is secured, which networks it connects to, which identity and security integrations are used, which resources are protected, and how access policies are defined.

ZTXGate is commercially supported software deployed outside a mandatory CoreZT-hosted access control plane. Self-hosted does not mean that the product is open source.

Keep the Access Platform Close to Your Resources​

On-Premises​

Run ZTXGate inside a data center, office, or other environment operated by the customer or MSP.

Cloud​

Deploy ZTXGate on a Linux VM alongside cloud-hosted infrastructure.

Hybrid​

Use the same access model with resources distributed between on-premises and cloud environments.

Air-Gapped​

Deploy ZTXGate inside isolated environments where the core access platform cannot depend on an external cloud service.

No Mandatory Vendor-Hosted Cloud Control Plane​

Some ZTNA architectures depend on a vendor-operated cloud service for control, policy, identity brokering, traffic handling, or other functions.

ZTXGate can be operated by the customer or an MSP. Core policy and access enforcement run within that ZTXGate deployment environment.

This can matter when an organization wants infrastructure under its own operational control, has internal or regulatory deployment requirements, operates applications that should remain independent of an external SaaS control plane, or has intentionally restricted Internet connectivity.

This does not mean that every optional integration works without external connectivity. If ZTXGate is configured to use an external identity provider, MDM platform, EDR platform, SIEM service, or third-party authentication service, that integration naturally depends on the corresponding service being reachable.

Explore the control-plane model

Architecture Under Your Control​

Managed endpoints use WireGuard-based connectivity for authorized access through ZTXGate. The platform can also support clientless HTTP/HTTPS access where that access model is appropriate.

The important point is that authorization happens through the selected ZTXGate deployment environment rather than requiring a CoreZT-hosted access plane.

Self-Hosted Does Not Mean Isolated From Existing Systems​

In connected environments, ZTXGate can integrate with systems already used by the organization:

• Identity: OIDC authentication and SCIM provisioning
• Device security: supported MDM and EDR posture inputs
• Authentication: ZTXBAS across all deployment models, plus Okta Verify Push and Duo Push where those cloud services are reachable
• SIEM: syslog, CEF, and JSON export

These integrations are optional components around the customer- or MSP-operated access platform.

Standalone or Centrally Managed with ZTXHub​

ZTXGate does not require a central CoreZT service to operate. A standalone deployment can manage access locally, including in a fully air-gapped environment.

For connected deployments that want centralized software update and license management, ZTXHub is an optional service owned and operated by CoreZT.

If ZTXHub is not used, ZTXGate remains independent. Licensing and software updates are handled manually instead.

ZTXBAS Across Every Deployment Model​

When licensed with ZTXGate, ZTXBAS is tightly integrated as a library and does not require a separate ZTXBAS server deployment. It works in connected, on-premises, hybrid, and fully air-gapped ZTXGate environments.

That gives deployments a phishing-resistant biometric authentication option that can remain inside the same deployment boundary. Cloud-dependent MFA services such as Okta Verify and Duo remain available where their respective services are reachable.

Explore ZTXBAS

Self-Hosted ZTNA vs Cloud-Delivered ZTNA​

Neither deployment model is automatically correct for every organization.

Cloud-delivered ZTNA can reduce infrastructure-management overhead. Self-hosted ZTNA provides greater control over where the access platform operates.

Self-Hosted Is More Responsibility Too​

Greater infrastructure control comes with operational responsibility.

The organization operating ZTXGate is also responsible for appropriate practices around host security, operating-system maintenance, network configuration, backups, recovery, availability planning, administrative access, monitoring, and product updates.

This is an intentional tradeoff.

Identity Without Giving Up Deployment Control​

A customer- or MSP-operated access platform can still use modern identity services. In connected environments, ZTXGate can authenticate users through an OIDC identity provider and use SCIM for identity lifecycle synchronization.

Where the access platform runs and which identity system the organization uses are separate architectural decisions.

Device Trust​

ZTXGate enrolls individual user devices and can make device identity part of policy. Where supported external posture services are available, compliance or risk information can also contribute to access decisions.

In isolated environments, policy naturally uses the identity, device, and security signals available inside that environment.

Air-Gapped and Disconnected Environments​

ZTXGate's core access platform can be deployed without depending on a CoreZT-hosted cloud control plane.

However, an air-gapped architecture must be considered as a whole. Internet-hosted identity, MDM, EDR, SIEM, or push-authentication services require connectivity if they are part of the deployment.

ZTXGate does not make an external dependency available inside an air gap; it allows the core access platform itself to remain inside the isolated environment.

Backup and Disaster Recovery​

ZTXGate does not provide conventional HA clustering. Instead, the administration portal can create periodic backups of the deployment.

If a deployment is lost, a backup can be restored into a fresh ZTXGate installation to recover the configured environment quickly. This is a backup-and-restore disaster recovery model, not active/active or active/passive failover.

Organizations should protect backup copies and plan replacement infrastructure and recovery procedures according to their own recovery objectives.

Who Should Consider Self-Hosted ZTNA?​

ZTXGate may be a good fit when:

• your organization already operates Linux infrastructure
• private applications live primarily on-premises or in cloud infrastructure operated by the customer or MSP
• you do not want core access to depend on a vendor-hosted control plane
• you operate hybrid infrastructure
• you need support for isolated or air-gapped environments
• deployment location is an architectural or regulatory consideration
• your team prefers infrastructure ownership over a fully vendor-operated SaaS model

A cloud-delivered service may be preferable when infrastructure ownership and maintenance are things your organization specifically wants to outsource.

Frequently Asked Questions​

Is ZTXGate open source?​

No. ZTXGate is commercially licensed and supported software deployed in infrastructure operated by the customer or an MSP.

Does ZTXGate require a CoreZT cloud account for core access?​

Core access operation does not require a mandatory CoreZT-hosted cloud control plane. Specific connected integrations naturally depend on their respective services.

Can ZTXGate run on-premises or in a public cloud?​

Yes. Both are supported deployment models.

Can ZTXGate operate in an air-gapped environment?​

ZTXGate can be deployed in isolated environments without requiring a CoreZT-hosted cloud control plane. The capabilities available depend on which identity, authentication, posture, monitoring, and supporting systems are reachable inside that environment.

Does self-hosting eliminate operational work?​

No. The customer or MSP operating the deployment is responsible for securing and maintaining the infrastructure hosting ZTXGate.

Do we need ZTXHub?​

No. ZTXHub is optional and is owned and operated by CoreZT. Standalone deployments use manual license and software update workflows, while connected deployments can use ZTXHub for centralized license and software update management.

Does ZTXGate provide high availability?​

Not in the conventional clustering sense. ZTXGate uses a backup-and-restore disaster recovery model so a saved configuration can be restored into a fresh deployment.

Keep Zero Trust Where Your Infrastructure Lives​

If your organization wants resource-level Zero Trust access while keeping the access platform within infrastructure operated by your team or MSP, ZTXGate provides a self-hosted deployment model.

Explore ZTXGate · Self-Hosted vs Cloud ZTNA · On-Premises ZTNA · Air-Gapped ZTNA · Explore Security & Trust