Security and deployment
What these products are designed to run inside, what was hardened in 2026, and what they deliberately do not do.
Xi-Batch and Xi-Text are infrastructure daemons designed to run inside a trusted operational zone - a data centre network segment, a server VLAN, or a single host. They are not designed to be exposed to untrusted networks, and we do not sell them for that.
Within that envelope they are appropriate and resilient, and on a single system with no network interfaces configured they are self-contained.
This page sets out what that means in practice, so you can deploy them correctly and know what you are getting.
The deployment model
Trusted zone
Both products authenticate peers by network identity and the configured host list. Place them inside your own trusted network segment and restrict access to it as you would any other infrastructure service.
Single host
Neither product requires networking. A single-system installation listens on nothing and is a perfectly ordinary, well-supported deployment.
Across untrusted links
Where traffic crosses a link you do not control -
between sites, over a WAN, through a cloud provider's network - carry it over an
encrypted tunnel. IPsec or WireGuard for a site-to-site link, SSH port forwarding
for occasional administrative access, or stunnel where per-service wrapping
suits you better.
We document the network surface - the ports each product uses and what each is for - so you can restrict them precisely rather than guessing.
Hardening
A cross-cutting security campaign shipped in Xi-Text 1.25.4 and Xi-Batch 1.9.1 on 20 July 2026, covering:
- Input validation at the network trust boundary
- Bounded handling of wire-supplied lengths
- Session keys drawn from the kernel's cryptographic random source
- Fail-safe privilege handling across all commands and services
- Compile-time assertions locking the wire and shared-memory layouts
The release notes record this and every other change, release by release.
What we deliberately did not change
The campaign did not change the network protocol.
The protocol is a compatibility contract with customers who have built integrations around these products over decades. Breaking it to add authentication would break those integrations, and that is not a decision to take in a patch release.
The honest position: materially more resilient against a hostile peer, with the protocol's trust model unchanged. V2 addresses the trust model architecturally, and Xi-Exec already provides mutual TLS, centralised access control and structured audit for remote execution today.
What these products do not do
Stated plainly, because you will establish it in an evaluation anyway:
- No transport encryption on the products' own wire protocol - use a tunnel where the link is untrusted
- No cryptographic authentication of peers; trust is by network reachability and the configured host list
- No user authentication independent of the host's own accounts
If any of those is a requirement today, Xi-Exec is the answer for remote execution, and we should talk about your timeline against V2.
Host-level deployment
- The daemons run under a dedicated service account, created at install time
- Packages install to standard filesystem locations with the ownership and modes the package sets; keep them
- Spool directories hold job and print data; their permissions are the access control on that data
- Apply product updates - security work ships in ordinary releases, and a customer several versions behind does not have it
Access control within the products
Both products have their own permission models, independent of the deployment question above.
Xi-Batch
A user - person or application - must be defined before Xi-Batch accepts work from them. Permissions control which operations each may perform, including whether they can see other users' jobs; by default they cannot. Xi-Batch can act as gatekeeper for remote submission, so a user does not need a login on a remote host to run work there.
Xi-Text
Class codes control which printers a group or user can reach and what privileges they hold within that group. This is how sites keep cheque stock and payroll output on printers most of the organisation cannot touch.
Planning a deployment?
Tell us your network layout and we will tell you where the boundaries should be.