Deploy Unison to Europe — Content-Addressed Distributed Language on EU Infrastructure in 2026

Every programming language has a source file. Functions live in files. Files live in directories. Directories live in repositories. Repositories have branches, merge conflicts, dependency manifests, lock files, and version numbers that eventually drift between environments. This is so fundamental to software development that questioning it feels strange — but it is not a law of nature. It is an accident of history, a convention carried forward from batch-processing mainframes into the networked, distributed, multi-node reality of modern software.

Unison is a programming language that replaces the source file as the unit of code with a content-addressed store. Every function in Unison is identified not by its name or its file location, but by the hash of its syntax tree — its actual definition. Functions can be renamed without breaking anything. Refactoring is semantic, not textual. Dependencies are exact: you don't depend on library@version, you depend on the specific hash of the function you need, which never changes. The consequence is a language with no dependency hell, no breaking changes from renames, and a codebase that is its own audit trail — every version of every function is addressable by hash forever.

Unison was created by Rúnar Bjarnason 🇮🇸 and Paul Chiusano 🇺🇸, co-authors of Functional Programming in Scala (Manning, 2014), with significant contributions from Arya Irani 🇺🇸 and the broader Unison team. Rúnar Bjarnason is Icelandic, and Iceland is an EEA member state — the European Economic Area integrates Iceland fully into the EU's single market, including the EU's data protection regime under the GDPR, which applies directly to Icelandic data processors and controllers. This is not a candidate-country relationship; it is full GDPR application. Unison's EU-adjacent origin, combined with its content-addressed architecture that makes code histories immutable and auditable, positions it naturally for GDPR-constrained deployments.

Unison applications deploy to sota.io on EU infrastructure with full GDPR compliance. This guide shows how.

The European Unison Team

Rúnar Bjarnason 🇮🇸 — Icelandic software engineer — is co-creator of Unison and co-author of Functional Programming in Scala, the canonical reference for functional programming on the JVM. Bjarnason's work has shaped how a generation of Scala developers think about referential transparency, monads, and type-driven design. His influence in the functional programming community spans the Scalaz and Cats libraries, the Haskell community, and now Unison's radical rethinking of what a codebase is. Iceland's EEA membership means Bjarnason's work is produced within the European legal space: Icelandic developers and companies are subject to GDPR, operate within the EU digital single market, and participate in EU research programs. Unison's development, though it has a US-based company (Unison Computing) driving it, carries this EEA DNA in its founding authorship.

Bjarnason's specific contribution to Unison is the language's functional core — the type system, the effect system (Unison's "abilities"), and the theoretical foundation borrowed from decades of functional programming research. His background writing FP in Scala with Paul Chiusano gave him deep expertise in the pedagogical challenges of teaching functional concepts to programmers from imperative backgrounds. That experience shaped Unison's design philosophy: powerful concepts (content addressing, abilities, distributed computing) made accessible through a syntax that feels familiar to FP practitioners without the notational overhead of Haskell or the complexity of dependent type theory.

Paul Chiusano 🇺🇸 — American software engineer, Unison Computing founder — is co-creator of Unison and co-author of Functional Programming in Scala. Chiusano's driving motivation for Unison was a problem he observed repeatedly in large Scala codebases: the impossibility of performing large-scale refactoring without breaking dependency chains, the cognitive load of managing versioned interfaces across distributed systems, and the fundamental fragility of name-based code identity. His answer was content addressing: if every function is identified by its definition hash, not its name, then names are just human-readable labels for mathematical objects. You can relabel them without breaking anything. The function is its hash; the name is a human convenience.

Chiusano's work on Unison's distributed computing model — the ability to send computations (not just data) across the network, to pause a running computation and resume it on a different node — is the feature that sets Unison apart from most functional languages that target single-node deployment. A Unison program can be suspended mid-execution, serialised to a byte string, sent to a remote node, and resumed there with full fidelity, because the computation's dependencies are content-addressed and universally resolvable. This is not remote procedure calls with a DSL on top — it is a language-level primitive for distributed computation.

Arya Irani 🇺🇸 — American software engineer, Unison Computing — leads significant work on Unison's tooling, the UCM (Unison Codebase Manager), and the Share platform for publishing and discovering Unison libraries. UCM is not a package manager in the traditional sense: it is a database browser for your content-addressed codebase. You navigate your code as a namespace tree, add terms by their hash, and publish to Unison Share where each library is identified by the exact hash of every function it exposes. No versioned tarballs, no semantic versioning, no lock files — just hashes that resolve to the same code everywhere.

Why Unison for EU Backends

Content-addressed code as an audit trail. Under GDPR Article 5(2) (accountability principle) and Article 30 (records of processing activities), EU data controllers must be able to demonstrate that data processing logic conforms to stated purposes. In traditional code, this is difficult: function names can be reused for different implementations, deployments can drift from source, and "what version ran on that date" is a forensic question requiring git archaeology. In Unison, every function that ever ran is identified by an immutable hash. The processing logic that handled a specific data subject's request can be retrieved by hash years later — it is an exact, byte-for-byte reproduction of the code that ran. For GDPR audits, data subject access requests under Article 15, and cross-border data transfer documentation under Chapter V, Unison's immutable code history is a natural fit.

Abilities for GDPR-compliant effect tracking. Unison's type system tracks side effects through "abilities" — the language's equivalent of algebraic effects or effect types. An ability in Unison is a named capability that a function requires:

-- A handler that needs database access and logging
processDataSubjectRequest : DataSubjectId -> {Database, Log, GDPR} DataExport
processDataSubjectRequest subjectId =
  record = Database.lookup subjectId
  Log.audit "Data access request" subjectId
  GDPR.generateExport record

The type signature {Database, Log, GDPR} tells you — and the compiler — exactly what side effects this function performs. You cannot call processDataSubjectRequest in a context that does not provide Database, Log, and GDPR abilities. The abilities are not documentation; they are compile-time constraints. For EU backends where GDPR Article 25 (data protection by design) requires that privacy controls are built into the system rather than bolted on, Unison's ability system turns GDPR constraints into type-checked guarantees.

No dependency hell for regulated software. EU public sector deployments, FinTech applications under MiFID II, and healthcare software under the EU Medical Device Regulation (MDR) all face compliance requirements around software supply chain documentation. The EU Cyber Resilience Act (CRA) — effective 2027 — requires vendors to produce Software Bills of Materials (SBOMs) and manage transitive vulnerabilities across their dependency trees. Unison's content-addressed dependency model eliminates this class of problem: every dependency is an exact hash, not a semver range. There is no "compatible version" ambiguity. The SBOM for a Unison service is its content-addressed namespace: a set of hashes that resolve to specific, immutable function definitions. No node_modules drift, no Maven dependency resolution conflicts, no pip freeze discrepancies between dev and prod.

Distributed computing for multi-region EU deployments. Unison's native distributed computing primitive — the ability to serialise and resume running computations — enables architectures that are difficult to build in conventional languages. An EU data processing pipeline can move a computation from a German node to a French node mid-execution, with the computation carrying its exact state, its dependencies (by hash), and its partial results. For EU multi-region deployments where GDPR data residency requirements mandate that specific processing stages occur in specific jurisdictions, Unison's computation mobility gives you precise control over where each step executes.

Immutable namespace history for reproducible builds. Unison's codebase is a persistent, immutable namespace: every term you add is stored forever by hash. Builds are reproducible by definition — the hash of the function is the function, and hashes are globally stable. For EU regulated environments where audit trails require demonstrating what code ran at a specific time, Unison's namespace history provides this without additional tooling. You do not need a separate artefact repository, a locked container image registry, or a point-in-time snapshot process — the codebase is its own point-in-time snapshot.

Deploy Unison on sota.io

sota.io runs on Hetzner infrastructure in Germany. Data stays in the EU by default. GDPR compliance is structural, not configurable. Unison services deploy as Docker containers.

Prerequisites

• sota.io account (sign up at sota.io)
• Docker installed locally
• Unison toolchain (ucm) installed

Step 1 — Write a Unison HTTP service

Unison supports HTTP servers through the http ability and ecosystem libraries on Unison Share. A minimal HTTP service:

-- Fetch this from Unison Share:
-- lib.http (content-addressed, resolved by hash)

handleRequest : HttpRequest -> {Http, Log} HttpResponse
handleRequest req =
  Log.info ("Request: " ++ HttpRequest.path req)
  match HttpRequest.path req with
    "/health" -> HttpResponse.ok "OK"
    "/data"   -> HttpResponse.ok (serveData req)
    _         -> HttpResponse.notFound "Not found"

main : '{IO, Exception} ()
main = do
  port = 8080
  Http.serve port handleRequest

Compile to a native executable with the Unison transcripts and the ucm run command, or build a Docker image using the Unison Dockerfile base.

Step 2 — Containerise

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y curl && \
    curl -L https://github.com/unisonweb/unison/releases/latest/download/ucm-linux.tar.gz | tar xz -C /usr/local/bin && \
    apt-get clean

WORKDIR /app
COPY . .

EXPOSE 8080
CMD ["ucm", "run", "main"]

For production builds, compile the Unison service to a native binary using the Unison compiler's native target — the resulting binary runs without UCM and produces a minimal Docker image.

Step 3 — Deploy to sota.io

# Install sota CLI
curl -sSL https://sota.io/install.sh | sh

# Initialise project
sota init

# Deploy — builds Docker image, pushes to EU registry, starts service
sota deploy

# Check status
sota status

Your Unison service is now running on Hetzner infrastructure in Germany. Traffic goes to your-project.sota.io over HTTPS automatically.

Step 4 — Connect PostgreSQL

# Provision a managed PostgreSQL instance
sota postgres create --name unison-db

# Get the connection string (injected as environment variable)
sota postgres env unison-db

In your Unison service, read DATABASE_URL from environment and use the sql ability for database access. The managed PostgreSQL instance runs in the same Hetzner data centre as your service — no cross-region data transfer, no Cloud Act exposure.

Unison, Iceland, and the EEA

Iceland's relationship with the EU is qualitatively different from that of EU accession candidate countries. As an EEA (European Economic Area) member since 1994, Iceland is fully integrated into the EU's single market for goods, services, capital, and persons. The GDPR applies to Icelandic data processors and controllers in exactly the same way it applies to German or French ones — Article 3's territorial scope, Chapter V's cross-border transfer rules, Article 83's administrative fines. Iceland is not a third country under GDPR; it is part of the EEA's integrated data protection space.

This matters for software provenance. When Rúnar Bjarnason co-created Unison, he brought to it the sensibilities of a developer operating within this integrated European legal and cultural space — the importance of code auditability, the value of systems where side effects are explicit and controllable, and the functional programming tradition that the EEA's Nordic and Icelandic developer communities have contributed to alongside Edinburgh, Cambridge, and the Dutch research universities.

Unison's effect system (abilities) descends from the same theoretical lineage as Koka (Daan Leijen, 🇳🇱 Microsoft Research), Eff (Andrej Bauer 🇸🇮, University of Ljubljana), and Frank (Sam Lindley 🇬🇧, University of Edinburgh) — algebraic effects developed in EU and EEA research institutions. Rúnar Bjarnason's Icelandic EEA origin, combined with this theoretical pedigree, makes Unison the most EEA-native of the content-addressed distributed languages.

Comparison: Unison vs Conventional Deployment Models

GDPR and Content-Addressed Code

GDPR compliance for Unison services on sota.io:

Data residency: All data processed by your Unison service stays in Hetzner's German data centres. No automatic replication to US regions, no US-parent-company Cloud Act exposure.

Processing records (Article 30): Unison's content-addressed namespace provides an automatic processing record. Every function that processes personal data is identified by a stable hash that you can include in your ROPA (Record of Processing Activities). The hash is the function — a DPO reviewing the audit record can retrieve the exact code that ran at any point in time.

Data protection by design (Article 25): Unison's ability system enforces privacy controls at the type level. You define GDPR-related abilities (Consent, DataAccess, AuditLog) and the compiler ensures that functions claiming to implement privacy-preserving behaviour actually carry those abilities in their type signatures.

Right to erasure (Article 17): Unison's ability to serialise, inspect, and transform computations makes right-to-erasure workflows implementable as first-class language features rather than SQL scripts bolted onto an application layer. A data subject's identifier flows through your system as a typed value; the ability to find and erase all occurrences is a property of the type system, not a documentation convention.

Why sota.io for Unison

EU infrastructure by default. Hetzner Germany. No US region fallback. GDPR data residency without configuration.

Managed PostgreSQL. Provisioned in the same data centre as your Unison service. Connection strings injected as environment variables. Backups, failover, and version upgrades managed.

Zero DevOps. Push code, sota deploy, done. No Kubernetes clusters to manage, no ingress controllers, no TLS certificate renewal scripts.

Flat-rate pricing. Predictable cost without per-request metering. Suitable for regulated industries where budget predictability is a compliance requirement.

German company. No US legal jurisdiction. No Cloud Act exposure. Data processing agreements under GDPR Article 28 with a German data processor.

Unison's content-addressed code, ability-typed effect system, and native distributed computing model make it one of the most architecturally interesting deployment targets for EU regulated workloads. sota.io provides the EU infrastructure that Unison's design deserves — GDPR-compliant by default, running in Germany, managed and maintained so your team can focus on the code, not the operations.

Deploy your first Unison service to EU infrastructure →