Getting started
This guide explains the initial ZTXGate deployment workflow at a product level. It deliberately avoids release-specific installer commands and exact setup-script prompts.
System requirements
ZTXGate is designed for a lightweight, single-node deployment.
| Requirement | Minimum / supported baseline |
|---|---|
| Operating system | Ubuntu 24 or later |
| CPU | 2 CPU cores minimum |
| Memory | 2 GB RAM minimum |
| Deployment model | Single node |
| Software package | One ZTXGate Debian (.deb) package |
The minimum CPU and memory values are a starting point. Production sizing should take into account concurrent users, traffic volume, clientless proxy usage, integrations, and logging requirements.
Before you begin
Before installation, plan the basic deployment-level information that the setup process will need, including:
- the FQDNs and/or IP addresses that will identify the deployment;
- the listener ports appropriate for your environment;
- the certificates that will be used for production TLS; and
- network reachability for the access methods and external integrations you intend to use.
Managed endpoint access uses WireGuard-based connectivity, so the network path must permit the configured WireGuard traffic. External services such as identity providers, MDM/EDR platforms, SMTP relays, or other cloud integrations must also be reachable if you enable them.
Optional license file during bootstrap
If you already have a ZTXGate license file, it can be placed in /tmp before installation or initial setup. Both the Debian-package installation process and the setup script can pick up a license file from that location.
You do not need to rely on /tmp for later license changes. Subsequent license updates are handled in the Admin Portal.
1. Install the ZTXGate package
Install the supplied ZTXGate .deb package on the prepared Ubuntu host.
The package contains the ZTXGate components required for the single-node deployment. At this stage, the software is installed, but deployment-specific network and certificate settings still need to be initialized.
2. Run the initial setup script
After the package installation succeeds, run the ZTXGate setup script.
The setup script performs the low-level bootstrap configuration, including settings such as:
- FQDNs and IP addresses;
- listener ports;
- certificates; and
- related deployment-level network parameters.
During this stage, ZTXGate also creates the WireGuard configuration and the credentials for the bootstrap administrator.
Protect the bootstrap administrator credentials because they provide the initial administrative access needed to continue configuration in the portal.
3. Sign in to the Admin Portal
Use the bootstrap administrator credentials created during setup to sign in to the ZTXGate Admin Portal.
From this point onward, most security and operational configuration is performed in the portal rather than in the low-level setup script.
4. Complete the high-level configuration
Configure the integrations and services required for your environment. Depending on the deployment, this can include:
- Authenticators and additional verification methods;
- SMTP for workflows that send email;
- OIDC for authentication and single sign-on;
- SCIM for user provisioning and identity lifecycle synchronization;
- SSF for shared security signals;
- MDM/EDR integrations for device posture; and
- license updates.
You do not need to enable every integration for an initial evaluation. Start with the capabilities required for the access path you want to test, then add integrations incrementally.
5. Create or synchronize the first user
Establish the identity that will be used for the first access test.
Depending on your configuration, users can be created through the appropriate administrative workflow or synchronized through the configured identity lifecycle integration.
For normal email-based enrollment workflows, configure SMTP before issuing an enrollment token.
6. Enroll the first device
Create an enrollment token for the user and complete enrollment on the endpoint.
For managed access, enrollment associates the endpoint with the user and prepares it for WireGuard-based connectivity through ZTXGate. The device can then be evaluated independently as part of access policy.
7. Define the first protected resource
Create a resource representing the application, host, or service you want to protect.
For the first test, choose a narrowly scoped resource whose connectivity and expected protocol are easy to verify. This makes it easier to distinguish policy problems from ordinary network or application issues.
8. Create the first access policy
Create a policy that authorizes the test user and enrolled device to reach the resource.
A simple first policy is usually better than beginning with many conditions. After the basic path works, you can add posture, time, network-location, temporary-access, or additional-authentication requirements as needed.
Where appropriate, use the built-in policy simulator to evaluate the intended (user, device, resource) decision before relying on the policy in production.
9. Validate the first connection
Connect from the enrolled endpoint and confirm that the authorized resource is reachable through ZTXGate.
Then review the relevant access, authentication, and policy records in the portal. This confirms not only that connectivity works, but also that ZTXGate is making and recording the expected access decision.
Clientless HTTP/HTTPS evaluation
If your deployment includes the licensed clientless-access capability, HTTP/HTTPS applications can be evaluated through the browser-based proxy path instead of the managed WireGuard endpoint path.
The resource and policy concepts remain the same, but the endpoint does not need WireGuard installed for that clientless web-access flow.
Air-gapped deployments
The same basic deployment stages apply in an isolated environment. Keep in mind that integrations with external identity, MDM, EDR, SIEM, SMTP, or cloud authentication services require those services to be reachable.
A standalone ZTXGate deployment can use manual license and software-update workflows when no external CoreZT service is available.
Next steps
After the first connection works, continue with the areas most relevant to your deployment: