9 posts tagged with "Platform"

Frontend 2.17.10 is, above all, a repair release for the Management console. In 2.17.9, selecting a VM in Management > Running VMs produced an empty actions menu, so actions administrators rely on there, such as Power, View logs and Set project, were unavailable. Viewing a VM's users could also show a blank screen or an error. This release fixes both.

Alongside the repairs, bulk VM shutdown is back, every authorized user on a running VM now shows a copyable user ID, and eleven more fixes cover virtual machines, Vault storage, and layout across the interface.

Backend 3.14.1 is a storage and API release. The headline is that file garbage collection works again: files left behind by deleted users and removed directories have not been reclaimed on most deployments for a long time, and this release fixes the reason. Alongside it, the API gains multi-type tokens, ten read-only administration routes, and a capabilities endpoint that lets a client ask the backend what it supports rather than guess from a version number.

Nothing in this release reclaims storage on upgrade. The garbage collector ships disabled and in dry-run, and taking it live is a deliberate, staged decision documented in full below.

Two releases shipped on 30 September. 4.1.1 carries the substance: transfers are faster and no longer hang, Windows installs from an MSIX package that upgrades in place, and about thirty fixes land across deployments, cloud drives and SFTP. 4.1.2 adds a reworked Windows window frame.

Sites moving large datasets through SFTP inboxes reported a specific, frustrating pattern: a big transfer would complete, and then the next transfer would fail. Sometimes it took a single multi-gigabyte file, sometimes a directory with thousands of small ones. SFTP 1.5.1 fixes that, and rebuilds the upload pipeline underneath it.

tiCrypt research VMs are air-gapped by design. They have no outbound internet access, which is fundamental to the security model but creates a practical problem: researchers need Python packages, and pip install needs a network. This article explains how the offline PyPI mirror solves that problem, why the isolation model works the way it does, and what the download strategy looks like under the hood.

For step-by-step instructions, see the admin setup guide and the researcher usage guide.

tiCrypt has no hardware vendor lock-in. It runs on commodity x86_64 servers, standard networking, and whatever storage you already have. But "hardware agnostic" does not mean "no requirements."

On June 18, 2026, tiCrypt gets its first major visual update in a few years. The redesigned front-end (v2.17.0) will be available from the Tera Insights repository, and this release is dedicated entirely to one thing: the experience.

We listened to feedback from researchers and administrators across our deployments and rebuilt the interface around how you actually work, while leaving everything beneath it untouched. There is no migration and nothing new to learn; every workflow, process, and security mechanism is exactly as it was.

What is new

• A true dark mode, alongside a refined light mode
• Cleaner iconography for faster recognition across the platform
• Better use of space, so screens feel less crowded
• Flexible layouts that bring the most relevant details to the front

What is next

This release is a starting point. As more researchers share feedback, we will continue to adapt and improve. This redesign also lays a long-term UX foundation for building much larger features.

Getting the update

Front-end v2.17.0 ships June 18, 2026, from the Tera Insights repository. Administrators can pull the latest release to roll it out across their deployment. For deployments that pull directly from the Tera Insights repository, users will automatically receive the update when they launch the application.

Why Audit Is Not Optional​

Compliance frameworks like CMMC 2.0 Level 2 do not treat audit logging as a best practice. They treat it as a requirement. The Audit and Accountability (AU) domain of CMMC, mapped directly from NIST SP 800-171 Revision 2, defines nine controls that govern how systems must create, retain, protect, correlate, and report on audit records. These controls exist for a reason: without a trustworthy audit trail, there is no forensics, no accountability, and no way to prove that CUI was actually protected.

tiCrypt was designed from the start with the assumption that every action must be recorded and that records must be resistant to tampering. This article explains how tiCrypt's audit system works, what it captures, how it supports forensic investigation, and how it maps to the CMMC AU controls that organizations are assessed against.

tiCrypt's security model is designed to protect data once it's inside the secure enclave. But in practice, the first question administrators and researchers ask is more immediate: how does data get in?

tiCrypt supports several ingress methods, each built for a different set of constraints, including dataset size, whether the sender has tiCrypt credentials, where the data needs to land, and who owns the process. This post breaks down each option and when to use it.