The team can deliver an application and model into an offline zone with evidence for the integrity of the entire release.
An offline environment cannot finish an update over the internet. Every release therefore arrives as a complete, signed package. A changed file, invalid signature, or missing receipt stops the process before startup.
Problem, solution, and result
Why a normal update cannot work here
The zone cannot download a missing file, patch, or dependency. The recipient needs a complete package that can be verified without contacting the supplier.
What the system does
The process builds a package containing the application, configuration, and file manifest, then signs it. Inside the zone, a public key verifies the signature and every hash. Startup is allowed only after all checks pass.
What we tested
In the recorded test, a correctly signed package passed and an intentionally changed file was rejected. Four artifacts matched the signed manifest. The test also covered 180 synthetic records and a signed test receipt. After a successful internal PostgreSQL check, none of 4 outbound probes through HTTP, HTTPS, DNS, and raw TCP connected. This local technical validation does not certify the client's environment.
For whom
This fits an environment that prohibits outbound traffic and requires every application, model, or index update to arrive as a verifiable offline release.
Package → verification → startup → receipt
- 01The manifest identifies every release file
- 02The zone verifies signatures and hashes locally
- 03The architect approves the release from the receipt
- Best for
- Critical-infrastructure operators and teams working in isolated zones
- Release package
- The application and models in a signed package with a file list and checksums
- Human decision
- A security architect approves the release after signature, file, and network-boundary checks
- Cost
- PLN 0 in external API fees; the local GPU answer took 1.765 s and up to 1.787 GB of memory.
- Security
- A changed file, invalid signature, or outbound connection attempt stops startup.
- Audit trail
- A signed receipt links the check result to a specific package, environment, and execution time.
- Similar system build
- from €6,000 net (approx. $6,500) · 4–10 weeks
Zone boundary
Who approves the release
A missing signature, changed file, or mismatched hash stops the process. The security architect reviews the evidence and approves startup. The receipt binds that decision to the exact manifest hash.
- Cost
- PLN 0 in external API fees; the local GPU answer took 1.765 s and up to 1.787 GB of memory.
- Security
- A changed file, invalid signature, or outbound connection attempt stops startup.
Why a historical field remains in the package
The signed package contains a field describing an earlier offer state. Changing it would invalidate the signature and linked receipt, so it remains unchanged. The public package also contains no result for the target 11B model. That measurement belongs on the client's hardware.
Estimated impact
Calculate the impact at your volume
This estimate uses the stated volume. Enter your own numbers to assess the possible impact in your company. The result is confirmed only during a pilot.
Today
12 engineering days/yr
With the system
6 engineering days/yr
Time or cost saved
4–8 engineering days/yr, base scenario 6
- Volume
- 4 releases/yr
- Formula
- 4 releases/yr × (3.0 − 1.5 days) = 6 days/yr
- Calculation status
- low-medium
Data in the screenshots. The names, amounts, and documents shown in the screenshots are synthetic. Client data remains private. Measurements describe the demonstrator and are kept separate from production outcomes.
Working views
The security architect approves startup. The system supplies locally verifiable evidence for the decision.
The architect can see what entered the zone, who signed it, whether every file matches the manifest, and whether the environment blocked outbound traffic. The process ends with a receipt tied to the specific release.
Package, boundary test, and acceptance receipt.
Package intake
Manifest, file hashes, and signature-verification result.
Boundary test
HTTP, HTTPS, DNS, and TCP probe results for the release.
Acceptance receipt
A signed record tied to the manifest hash.
System screens
See how the system works in practice
These desktop and mobile screenshots come from the running application. They show the process and the points where a person makes the decision.
- Screens
- 10
- px
- 1440 · 390
- 021440×2822
Signature and file-hash verification. - 031440×1100
Mobile release-intake view.
Open the remaining screen archive (7)
- 041440×1100
Changed manifest rejected - 051440×1100
Airlock register - 061440×1100
Held package with a recorded reason - 071440×1100
Held handovers - 081440×1100
Egress probes - 091440×1100
Admission profiles - 101440×1100
Public evidence scope
Technology stack
A release path built from tools the zone can check by itself.
An environment with no outbound traffic rules out every service you would have to connect to, so the stack is signatures, digests, and local artifacts: the model loads from files carried into the zone, and every update enters as the next signed release. Audit reads plain files and signed receipts, with no trust placed in anything outside.
- Python and FastAPI
- the release API and integrity checks inside the zone
- cryptography (RSA-3072, SHA-256)
- the bundle signature and the digest of every file in the manifest
- PostgreSQL 17 with pgvector
- the register, documents, and a non-exporting audit trail
- vLLM with the Bielik model
- the GPU profile serving a local model from in-zone artifacts
- Docker Compose, the perimeter network
- an internal network with no egress, tested at every release
- Next.js
- the operator console exposed on a local port only
The client owns the code, prompts, evaluation data, and the release-path documentation. We use open components; the whole system runs inside the client's zone and sends nothing out, telemetry included.
Technical details and measurements
How the system works
The zone accepts only a package it can verify on its own.
Every file has a hash in the signed manifest. A public key inside the zone confirms the sender and integrity. An incomplete or changed package stops before startup.
Complete application and model package
SHA-256 manifest and RSA-3072 signature
The zone verifies the signature and every file
Missing evidence stops the release
Startup and HTTP, HTTPS, DNS, and TCP tests
Signed receipt tied to the release hash
System architecture
Manifest, signature, internal network, and receipt.
A cryptographic release path, a runtime with no exit, and a validation record bound to the bundle's exact hash.
- 01
Bundle
The manifest lists every file with its digest.
The release is a bundle with a SHA-256 manifest of all artifacts and an RSA-3072 signature over the whole. What is absent from the manifest is not part of the release.
- 02
Verification
The recipient checks, the sender cannot help.
A public key held inside the zone verifies the signature, and the private key stays outside. A changed file or a digest with no match stops the path with no service exception.
- 03
Runtime
Everything lives on an internal network.
The API, database, model, and control jobs run on the Compose network perimeter marked internal: true. The console also joins operator_console to expose a local port. The egress test first requires a positive Postgres control inside the network, then four failed exit attempts.
- 04
Receipt
Validation leaves a signed record.
The validation-zone run exists as a signed receipt bound to the manifest's exact hash, the environment identifier, and the execution time. Changing any field after signing invalidates the signature.
Why so few moving parts
In a zone with no exit, every added capability is one that must be verified offline, updated by signed transfer, and audited by people who cannot call us. The release path therefore uses the path is built from signatures, digests, and plain files the zone can check by itself.
- The manifest and signature are the condition of entry
- Verification happens entirely inside the zone
- A bypass path was deliberately never built
- The receipt binds validation to a specific release
Want to assess a similar process in your company?
- A 30-minute call with the engineer who would lead the work.
- A review of the processes that cost you the most time and money.
- A written summary of what to automate first and the likely cost range.
Times are shown in your own time zone. We work with clients across time zones.
The scan is free and creates no obligation. If automation is unlikely to pay off, the written recommendation will say so.