Hybrid deployment

Seal’s standard cloud deployment handles most organisations. Cloud storage is US$10 per TB per month (ingress free), a 1 TB dataset transfers in under 3 hours on 1 Gbps, and you get unified search, AI, and dashboarding across all your data with zero on-premises infrastructure. Hybrid deployment exists for organisations with a hard constraint that prevents specific data from reaching the cloud:

• HPC co-location — analysis runs on a local cluster and data volumes make cloud transfer impractical between jobs
• Legacy network infrastructure — upload speeds genuinely limit cloud transfer of multi-terabyte data sets and upgrading connectivity is not feasible
• Regulatory mandate — a specific regulation or institutional policy requires certain data to remain on-premises (note: most data sovereignty requirements are satisfied by Seal’s regional hosting)

“We have sensitive data” is not a reason for hybrid. Seal’s cloud is SOC 2 Type II certified, encrypted at rest and in transit, and hosted in a private VPC. For patient data, anonymise it before it enters Seal. Seal has a full REST API — every action in the UI is available programmatically. The same API that powers the UI also powers on-premises integrations.

​

Architecture

In a hybrid deployment, Seal operates across three zones: Cloud (Seal Platform) — hosted on GCP:

• Scientific workflows, experiment design, and execution records
• General metadata and GxP audit trails (metadata only — no sensitive data persisted)
• User management, search, dashboarding, and AI features
• API orchestration between cloud and local environments

Customer network — on the organisation’s infrastructure:

• The Seal IoT agent runs on a local machine with access to your file stores and instruments. It watches for file events, computes checksums, and pushes metadata to Seal’s API over an encrypted connection. It’s the same IoT agent used for standard instrument data capture, configured to also handle file lifecycle tracking.
• Lab instruments output raw data to the local network as normal
• An embedded UI renders on-premises data and external tools inside the Seal interface via iFrame. Scientists access local data, analysis platforms, and other systems without leaving Seal. Traffic between the browser and local data stays entirely on the customer’s network.

Local data store — on-premises storage under the customer’s control:

• Large instrument files, sensitive data, and analysis outputs
• Managed by the customer’s infrastructure and security policies
• Seal references data by ID but never reads or stores the underlying content

Scientists work in one interface. Seal is the home screen — experiment records, workflows, search, and dashboards all live here. When a scientist accesses data stored on-premises, an embedded UI renders it inline within Seal. The browser loads that data directly from the local network — it never touches the cloud. External tools (LIMS, instrument booking, analysis platforms) also embed inside Seal via iFrame, so researchers access everything from one place without switching between systems.

​

Data should live in one place

The most important principle in a hybrid deployment: keep your on-premises data consolidated in a single, well-managed store — not scattered across instrument PCs, shared drives, and individual workstations. Seal is the single source of truth for what data exists, where it is, and what’s happened to it. If data lives on Seal (cloud), Seal manages it directly — storage, versioning, audit trails, search, and access control all work out of the box. If data stays on-premises, Seal stores references to that data (file paths, URIs, checksums) and maintains a complete event log of every change, movement, and access. The data never touches the cloud, but the audit trail does. Default to cloud. Reserve on-premises storage strictly for data that cannot leave your infrastructure. For data in external clouds (AWS S3, Azure Blob Storage, third-party SaaS), Seal stores a reference and tracks the lifecycle the same way — the experiment record holds the external URI, and every interaction is logged in Seal’s audit trail. Seal also supports real-time data streaming to external data warehouses (e.g. Snowflake) via Estuary. Raw data is streamed directly from the database — you’ll receive raw data blobs that are straightforward to restructure in your warehouse. See Infrastructure for details.

​

Tracking on-premises data through Seal

When data stays on-premises, Seal needs to know about every file event — creation, movement, modification, deletion, and access. This is achieved through wrapper functions that perform the local file operation and log the event to Seal as a side effect. During implementation, we set up a thin integration layer (typically Python scripts using Seal’s SDK and REST API) that wraps your local file operations. Each wrapper function:

1. Performs the operation — moves, copies, or writes the file on the local network
2. Computes a checksum — SHA-256 hash of the file before and after the operation
3. Verifies integrity — confirms the checksum matches at the destination
4. Logs to Seal — pushes an event to the experiment record via the API, including: file path, operation type, timestamp, operator, source and destination checksums, and success/failure status

Every file operation on your local infrastructure produces a corresponding audit entry in Seal — a GxP-compliant chain of custody without the files themselves leaving your network.

​

Automated file watching

Most lab instruments output files to a network folder automatically — flow cytometers produce FCS files, sequencers produce FASTQ/BAM files, plate readers produce CSV exports, imaging systems produce TIFF stacks. The Seal IoT agent monitors these folders continuously. When a new file appears, the agent:

• Matches it to the correct experiment record using configurable naming rules
• Computes and stores a checksum
• Logs the event to Seal (file created, location, size, hash, timestamp)
• Optionally uploads smaller files directly to Seal for cloud-based analysis

Instrument outputs are tracked from the moment they hit the file system. No manual logging required.

​

Reconciliation and accuracy checks

A periodic reconciliation job runs against the on-premises data store to verify that Seal’s records match reality:

• Walks the data store and inventories every file (path, size, checksum)
• Compares the inventory against what Seal’s event log expects to be there
• Flags discrepancies: missing files, unexpected modifications (checksum mismatches), untracked files
• Logs the reconciliation result as an event in Seal

This runs nightly or weekly depending on volume, and catches any file operations that happened outside of the tracked workflow.

​

HPC and analysis tools

Seal integrates with local HPC clusters, desktop analysis tools, and cloud analysis platforms — without modifying your infrastructure and without data leaving the local network unless explicitly directed.

​

Integration methods

All of these ship as part of the standard platform: Seal replaces spreadsheet registers, standalone freezer management, shared drive document management, and paper notebooks — one validated platform for inventory, storage, documents, and experiment records. Seal integrates with specialist tools — instrument booking, colony management, analysis platforms, LIMS, and data archives render inside Seal via iFrame or connect via the REST API. Scientists access everything from one interface. Every interaction is logged as an event in the experiment timeline.

​

Data sovereignty

Designated data never leaves your infrastructure. Metadata stored in Seal’s cloud is strictly limited to system events, anonymised record IDs, and timestamps — no sensitive content. If your research involves patient or participant data, anonymise it before it enters Seal — store coded IDs, keep the linkage key in a separate system. See Handling confidential data for specific guidance on PII anonymisation. During implementation, we define a data classification model that determines exactly what goes to the cloud and what stays local, then enforce it through the IoT agent configuration and API wrapper rules.

​

Security and compliance

Hybrid deployments maintain the same security posture as standard cloud deployments:

• Seal cloud — SOC 2 Type II certified (report available on our security portal), with all standard encryption and network isolation controls
• Encrypted connectivity — all traffic between the IoT agent and Seal uses mutual TLS (mTLS). Seal issues and manages the client certificates via its own CA. Certificates auto-rotate on a fixed schedule; no manual key management required on your end.
• Zero-knowledge — Seal’s cloud never accesses sensitive data stored on-premises. Only metadata and reference IDs cross to the cloud.
• GxP compliance — e-signatures, version control, change sets, and ALCOA+ work identically across cloud and hybrid. Audit trails capture the full experiment lifecycle regardless of where data is physically stored.

Your team is responsible for securing on-premises infrastructure, network connectivity, and local data backups. See also: Data storage and security, Backup and disaster recovery, Security portal.

​

Network requirements

The IoT agent initiates all connections — no inbound access to your network is required.

​

Restricted and air-gapped networks

For segmented networks or strict firewall policies, the requirements above are all that’s needed — outbound HTTPS on port 443, no inbound rules. For air-gapped environments where no persistent outbound connection is available, the IoT agent operates in batch mode: file events are queued locally with full checksums and timestamps, then synced to Seal when a network window opens. If no network window is available, the agent exports event logs as signed JSON files for transfer via an approved data diode or removable media.

​

What’s included vs. what’s custom

Here’s what ships today vs. what’s built during implementation:

​

Responsibility boundary

​

IoT agent

The IoT agent is a lightweight process that runs on a standard machine (Windows, macOS, or Linux) on your network. It auto-updates as part of Seal’s standard release cycle, resumes automatically after downtime, and writes structured logs locally for SIEM forwarding. Agent status is monitored from the Seal admin dashboard. Contact [email protected] for detailed IT specifications.

​

Data export and portability

All data in Seal — experiment records, metadata, audit trails, file references, and event logs — is exportable in standard formats: PDF, DOCX, CSV, and JSON. This includes the full audit history and version chain for every record. For hybrid deployments, Seal’s API provides programmatic access to every record in the system. You can bulk-export your entire dataset at any time. Your on-premises data stays on your infrastructure and is never locked into Seal. Seal stores references and metadata only — the underlying files remain yours, on your hardware, in your formats.

​

Implementation timeline

Hybrid configuration runs in parallel with the broader platform implementation (ELN, templates, training) — it does not extend the overall timeline.

​

Getting started

Contact your account representative or email [email protected] to discuss hybrid deployment for your organisation.