Infinito.Nexus 13.0 introduces a new choice in how organizations can operate their digital infrastructure.

Until now, an Infinito.Nexus environment was primarily organized around public or private clearnet domains. Version 13.0 adds Tor onion services as a first-class deployment option. An organization can now build its application landscape on the conventional Internet, through Tor, or through a combination of both.

This release includes:

• Tor as a first-class deployment axis
• Stable onion addresses generated during provisioning
• Tor-aware identity and Single Sign-On flows
• Optional parallel clearnet domains
• Cross-domain and cross-protocol SSO improvements
• Recovery tests based on real database dumps
• Mandatory health probes across containerized services
• Broader automated testing across Python, JavaScript, PHP and Ruby
• A consolidated and more secure CI deployment chain

Together, these changes extend digital sovereignty beyond the question of who operates the servers. Infinito.Nexus 13.0 also begins addressing where services can be reached, which network infrastructure they depend on and how much an organization must disclose merely to exist online.

Two Ways to Organize Digital Infrastructure

Clearnet remains the appropriate default for most Infinito.Nexus installations.

Public domains are easy to discover, work with conventional browsers and support established mechanisms such as public DNS, standard email delivery and Let’s Encrypt certificates. They are the natural choice for companies, public institutions, associations and communities that want their services to be broadly accessible.

But public reachability also creates dependencies.

Operating a conventional public service generally involves domain registrars, DNS providers, certificate authorities, hosting networks and publicly visible IP infrastructure. Each of these components can become a source of metadata, interference or pressure. In restrictive environments, they can also become points at which a service is identified, filtered, blocked or seized.

Tor provides a different organizational model.

With Infinito.Nexus 13.0, an organization can expose its cloud through a Tor v3 onion service. The server does not require a public IP address, inbound port forwarding, dynamic DNS or a conventional public domain. Applications are made reachable through .onion addresses, while Tor provides transport encryption and authenticates the onion service cryptographically.

This does not make clearnet obsolete. It creates a second path.

Organizations can now choose an architecture based on their circumstances:

• A conventional clearnet deployment for broad public accessibility
• A Tor-only deployment for infrastructure that should not depend on public DNS or exposed server addresses
• A mixed deployment in which selected services remain available on clearnet while onion access provides an additional route

Digital sovereignty is not achieved by forcing every organization into the same network model. It grows from the ability to choose between models without rebuilding the entire application landscape.

Tor as a First-Class Deployment Axis

Tor support in version 13.0 is not limited to placing a proxy in front of one application.

The new svc-net-tor role integrates onion networking into the deployment architecture. When enabled as the primary mode, the generated onion address becomes the primary domain of the node. Applications, virtual hosts, identity services and internal name resolution are configured consistently around that address.

One onion service can expose the complete environment. Individual applications remain separated through subdomains and are routed by OpenResty according to the requested host name.

The onion identity is generated during inventory provisioning and stored with the deployment configuration. This makes the address stable across redeployments and allows it to be restored from a secured backup. An organization does not receive a different address whenever the stack is rebuilt.

Version 13.0 also adapts application integration to this network model:

• Internal name resolution can route onion addresses through Tor.
• Server-side OIDC discovery and token exchange can reach onion-based identity providers.
• Applications that require special cookie handling on plaintext onion endpoints receive Tor-aware configuration.
• Mail authentication uses the submission endpoint actually exposed through the onion service.
• Deployment variants explicitly test Tor, clearnet and mixed configurations.
• Onion compatibility is enforced as part of the project’s validation model.

These details matter because network support is only useful when login, sessions and application-to-application communication continue to work.

Why This Matters in Authoritarian States

For civil-society organizations, independent media, opposition groups, unions, human-rights initiatives and informal communities in authoritarian states, digital infrastructure is not merely an operational concern. It can determine whether people are able to coordinate at all.

Conventional cloud services may be blocked. Domains can be seized or removed from DNS. Hosting providers can be pressured. Public IP addresses can reveal infrastructure locations. Administrators and members may face legal, political or physical risks.

A Tor-based Infinito.Nexus deployment can reduce some of these dependencies.

An organization can operate collaboration, publishing, file-sharing, project-management and communication tools without publishing the server’s network location through normal DNS. The infrastructure can run behind NAT or CGNAT, and its onion address remains independent of a traditional domain registrar.

This may enable organizations to:

• Coordinate work through self-hosted applications
• Maintain internal knowledge and documentation
• Share files without relying exclusively on foreign SaaS providers
• Publish information through infrastructure that is harder to block by domain or hosting IP
• Move a service while retaining its onion identity, provided its keys are preserved
• Reduce exposure to local DNS manipulation
• Offer an alternative access path when clearnet services are censored
• Keep identities and access rules under their own administrative control

The broader Infinito.Nexus application catalog is especially relevant here. An organization does not need to depend on one monolithic platform. It can assemble the tools it needs and connect them to a shared identity layer.

However, technology cannot remove the political danger surrounding its use. Tor access may itself attract scrutiny, and endpoint security, operational discipline, device compromise, account behavior and human relationships remain critical. Infrastructure is only one part of an organization’s threat model.

An Important Limitation: Tor Mode Is Still a Proof of Concept

The Tor mode introduced in Infinito.Nexus 13.0 must currently be treated as a proof of concept—not as a guarantee of anonymity.

Infinito.Nexus can route services through Tor and avoid several dependencies of a clearnet deployment. It cannot automatically change every application’s internal behavior.

Applications may still expose identifiable characteristics. Depending on the software and its configuration, these may include:

• External asset requests
• Embedded third-party content
• Analytics or telemetry connections
• Federation traffic
• Email delivery
• Webhooks and application integrations
• DNS requests outside the intended path
• Version and configuration fingerprints
• Links containing clearnet domains
• User-generated content with identifying metadata
• Browser behavior that correlates onion and clearnet activity

Some applications are designed with the public Internet in mind. They may assume that external APIs, content-delivery networks, mail servers or federation peers are available. Even if their web interface is served as an onion service, background communication can reveal information about the installation or create recognizable traffic patterns.

Users may also identify themselves through ordinary behavior—for example by reusing accounts, uploading files with metadata, opening external links, or accessing the same identities through both Tor and clearnet.

For these reasons, the presence of a .onion address must never be interpreted as proof that an organization, server administrator or user cannot be identified.

Version 13.0 provides the architectural foundation needed to test and improve this model. It does not claim that every application in the catalog has already undergone a complete anonymity audit.

Organizations facing serious threats should conduct an application-specific security assessment, define a realistic threat model and involve experienced operational-security professionals before relying on the Tor deployment mode.

This caution is especially important in authoritarian states, where a mistaken assumption of anonymity can have consequences far beyond data loss.

Optional Clearnet Access

Tor and clearnet are not necessarily mutually exclusive.

An application deployed on an onion-based node can receive additional public domains where its purpose requires conventional accessibility. Each endpoint retains the appropriate network and TLS behavior.

This allows organizations to separate audiences and functions.

A public website, for example, may remain available through a normal domain while an internal collaboration environment is accessible only through Tor. Alternatively, the same service may provide both a familiar public address and an onion address that remains reachable during DNS blocking or network censorship.

Mixed deployments require careful judgment. Offering both endpoints can improve availability, but it can also make correlation easier and undermine the separation an organization intended to create. The correct choice depends on whether the goal is censorship resistance, infrastructure-location protection, user privacy, organizational anonymity or simply an alternative access route.

Tor is a tool for building an architecture—not a substitute for defining what that architecture must protect.

Single Sign-On Across Networks and Protocols

A sovereign application platform becomes difficult to operate if each service maintains an independent identity database.

Infinito.Nexus 13.0 therefore continues the project’s focus on shared identity. This release improves Single Sign-On across domains and protocols, including new SAML integration alongside OpenID Connect, OAuth2 and LDAP.

Keycloak can now provision SAML clients for applications that require them. SuiteCRM uses this integration directly, while Shopware receives improved separation between browser-facing and internal identity communication. Cross-domain sessions and logout behavior have also been made more consistent.

These improvements are particularly important for Tor environments. Identity discovery, token exchange, redirect schemes, cookies and logout flows must all understand whether the user and the application communicate through onion or clearnet addresses.

For administrators, the principle remains the same: users, groups and application access are managed centrally instead of being recreated manually in every service.

Recovery Based on Real Data

Version 13.0 also strengthens disaster recovery.

The recovery tooling now replays database and cluster dumps from the selected backup generation. It reads the layout captured by that generation and restores each dump according to the database engine that created it.

The automated recovery drill empties the volumes it claims to test and verifies that the required databases were actually dumped before restoration begins. Backup timers are stopped before destructive recovery tests run.

This closes an important gap between having backup files and knowing that they contain enough information to rebuild a working environment.

For organizations operating under political or infrastructural pressure, portability and recovery are part of resilience. A service that can avoid public DNS but cannot be restored after hardware loss, confiscation or provider failure is not genuinely sovereign.

A Health Probe for Every Container

Infinito.Nexus 13.0 makes health checks mandatory for declared container images unless a role explicitly documents why a meaningful probe cannot be provided.

These checks target the ports services actually bind to and are defined centrally rather than being duplicated across proxy configurations. Diagnostics now record more precise evidence about DNS resolution, upstream resolvers, service startup and Swarm convergence.

The result is a platform that can distinguish more reliably between a deployed container and a working service.

This is especially valuable in Tor environments, where a failure may occur in the application, the reverse proxy, local DNS, the Tor daemon or the onion routing path. Better probes make those layers easier to separate during diagnosis.

Stronger Tests and a Safer Delivery Chain

The project’s quality gate now parses every programming language shipped by the repository and runs the corresponding unit suites. JavaScript, PHP and Ruby tests join Python in the CI summary.

The deployment workflows have also been consolidated into one validated chain. Deployment variants receive distinct test rows across operating systems, filesystems and Tor configurations. Retriggered runs preserve the selection that originally failed, while workflow permissions are restricted to the jobs that require them.

This matters because Tor support crosses many layers of the platform. It cannot be tested adequately through one isolated role. DNS, identity, cookies, application behavior, proxies and deployment modes must be exercised together.

A New Dimension of Digital Sovereignty

Infinito.Nexus 12.0 expanded the platform from a single server to a scalable sovereign cloud.

Version 13.0 adds another dimension: the network through which that cloud exists.

Organizations can continue to deploy on clearnet, use Tor as an alternative access path or experiment with onion-first infrastructure. They retain the same automation model, shared identity architecture, application catalog, backup strategy and operational tooling.

For customers, that means:

• A choice between clearnet, Tor and carefully designed mixed deployments
• Stable onion identities that survive redeployment
• Less dependence on public IP addresses, DNS providers and domain registrars
• Tor-aware Single Sign-On and application integration
• Better options for censorship-resistant organizational infrastructure
• More rigorous backup and recovery validation
• Mandatory service health checks
• Broader automated test coverage
• Clearer diagnostics across networking and application layers

The most important point is also the most cautious one: Tor mode expands what is possible, but it does not yet make every Infinito.Nexus application anonymous or free of identifiable behavior.

Version 13.0 is a proof of concept and an architectural foundation. Its purpose is to make onion-based sovereign clouds deployable, testable and improvable—not to promise protection that has not yet been verified application by application.

For organizations in authoritarian states, this foundation may open meaningful new possibilities for communication, collaboration and self-determination. Those possibilities must be developed with technical honesty, careful threat modeling and respect for the risks faced by the people who depend on them.

The complete technical details, fixes, dependency updates and compatibility changes are available in the Infinito.Nexus 13.0 changelog.

Infinito.Nexus 13.0 brings the project closer to a broader goal: enabling organizations to control not only their applications, identities and data, but also the network model through which their digital community can exist.