Deploy Lean 4 to Europe — Formal Verification and Theorem Proving on EU Infrastructure in 2026

Software testing tells you that your code works on the inputs you thought of. Formal verification tells you it works on every possible input — and a machine checks the proof.

For most software, this distinction is academic. For software that controls aircraft, processes medical records, authenticates financial transactions, or implements cryptographic protocols, the distinction is the difference between "we believe it works" and "we can prove it works." The EU AI Act, which began phasing in across 2024 and 2025, makes this distinction legally relevant for a much wider class of systems: AI components subject to Article 13 (transparency) and Article 15 (robustness and accuracy) must be explainable and verifiable in ways that traditional testing cannot satisfy.

Lean 4 is the intersection of two things that were previously in tension: a practical functional programming language for building real software, and an industrial-strength proof assistant for machine-checked formal verification.

Created by Leonardo de Moura at Microsoft Research, Lean 4 is simultaneously a dependently-typed functional programming language, a proof assistant, and a metaprogramming framework. You can write a sorting algorithm and prove its correctness in the same file, using the same type system. You can build an HTTP server that ships with machine-checked proofs of its core invariants. And Mathlib — the open-source mathematics library for Lean 4, built largely by European researchers — demonstrates that this approach scales: over 200,000 theorems formalised across algebra, topology, number theory, and analysis.

Lean 4 backends run on EU infrastructure. This guide shows how to deploy them with sota.io.

The European Lean 4 Research Community

Lean 4 is not a language that happened to attract European users. European institutions are core contributors to the ecosystem.

Sebastian Ullrich 🇩🇪 (Karlsruhe Institute of Technology → Microsoft Research) is the lead developer of Lean 4's compiler and elaborator. Ullrich completed his PhD at KIT (Karlsruhe Institute of Technology), one of Germany's leading technical universities, before joining de Moura at Microsoft Research to implement Lean 4 from scratch. The Lean 4 compiler's macro system, its efficient elaboration algorithm, and its incremental compilation infrastructure are substantially his work. KIT's presence at the origin of Lean 4's implementation makes Germany structurally central to the language.

Patrick Massot 🇫🇷 (Université Paris-Saclay) is one of Mathlib's most prolific contributors and a principal author of Mathematics in Lean — the standard tutorial for learning Lean 4 through mathematical formalisation. Massot's research group at Paris-Saclay works at the intersection of differential topology and formal methods. His sphere eversion formalisation — a proof that a sphere can be turned inside out, checked by Lean 4 — is one of the most technically demanding results in Mathlib.

Johan Commelin 🇳🇱 (Albert-Ludwigs-Universität Freiburg → Utrecht University) is a core Mathlib maintainer and co-led the formalisation of perfectoid spaces in Lean — the first machine-checked proof of a major result in modern algebraic geometry. Commelin's career spans the Netherlands and Germany; his work demonstrates Lean 4's capacity for research-grade mathematics, not just foundational exercises.

Floris van Doorn 🇳🇱 (University of Pittsburgh → University of Bonn) contributed to the foundational infrastructure of Mathlib and formalised key results in measure theory and real analysis. Van Doorn's institutional home at the University of Bonn — one of Germany's oldest and most distinguished research universities — gives Mathlib a direct connection to German mathematical research.

Kevin Buzzard 🇬🇧 (Imperial College London) is the most prominent public advocate for formalising contemporary mathematics in Lean. Buzzard's Xena Project at Imperial College London introduces undergraduate mathematicians to Lean 4, and his blog posts on formalising the Langlands Programme have generated widespread attention. Imperial College London is a leading research university in central London.

The TYPES European Network — funded under the EU COST Actions programme — brings together researchers from across Europe working on type theory and its applications to programming language verification. Lean 4 (alongside Agda, Coq, Idris, and Isabelle) is a primary system used within the TYPES network. EU funding has directly supported the formal verification research that Lean 4 implements.

Lean Together workshops — the annual gathering of Lean users and developers — have been held in Amsterdam (CWI), Paris, and other European cities. The European mathematical community's engagement with Lean 4 is not peripheral; it is the community's primary route from mathematical intuition to machine-checked proof.

INRIA (Institut National de Recherche en Informatique et en Automatique) 🇫🇷 — France's national research institute for informatics — has multiple research groups working with Lean 4. INRIA's longstanding strength in proof assistants (Coq was developed at INRIA) creates natural overlap with Lean 4, and several INRIA researchers have contributed to Mathlib.

The EU AI Act creates additional institutional pressure toward formal verification for AI systems deployed in Europe. Lean 4, as the most practical current system for combining formal proofs with real software, is positioned as a tool for EU AI Act compliance work.

How Lean 4's Type System Works

Lean 4's power comes from a single idea extended to its logical conclusion: types can depend on values.

In most programming languages, the type of a value is fixed at the type level — Int, String, List[User]. The values themselves cannot influence their types. In a dependently typed language like Lean 4, a type can contain a value as a parameter: Vector n α is the type of vectors of length exactly n, where n is a natural number value. The type system can then track the lengths of collections at compile time.

This is not just a party trick. It means you can write:

def head (v : Vector α (n + 1)) : α := v.head

This function compiles only if Lean 4 can prove the vector has at least one element. The (n + 1) in the type means "some positive number." Calling head on an empty vector is a type error — not a runtime exception.

Propositions as Types

The deeper power of Lean 4's type system is the Curry-Howard correspondence: logical propositions are types, and proofs are programs.

-- A theorem: the sum of the first n natural numbers is n*(n+1)/2
theorem sum_formula (n : Nat) : 2 * (Finset.range (n + 1)).sum id = n * (n + 1) := by
  induction n with
  | zero => rfl
  | succ n ih =>
    simp [Finset.sum_range_succ]
    omega

The theorem keyword introduces a proposition. The : 2 * ... is the type — the statement being proved. The by block is the proof term, constructed by the tactic system. Lean 4's kernel verifies that the proof term has the claimed type. If it does, the theorem is proved — machine-checked.

This is the same type checker that verifies your programs. The proof and the code live in the same language.

Tactics and Automation

Writing proof terms by hand is tedious. Lean 4 provides a tactic language — a domain-specific language for constructing proofs interactively.

-- Prove that list reversal is an involution
theorem reverse_reverse (l : List α) : List.reverse (List.reverse l) = l := by
  induction l with
  | nil => rfl
  | cons h t ih =>
    simp [List.reverse_append, ih]

The induction tactic generates two proof goals — one for the empty list (nil) and one for non-empty lists (cons). rfl closes goals that are definitionally equal. simp applies simplification lemmas automatically. omega solves linear arithmetic goals. These tactics are themselves implemented in Lean 4 using its metaprogramming system.

Lean 4 as a Programming Language

Lean 4 is not just a proof assistant — it is a practical functional programming language with monadic effects, do-notation, and a capable standard library.

import Std

def fibonacci : Nat → Nat
  | 0 => 0
  | 1 => 1
  | n + 2 => fibonacci n + fibonacci (n + 1)

-- With memoisation via cached computation
def fibMemo : Nat → Nat := fun n =>
  let rec go : Nat → Nat × Nat
    | 0 => (0, 1)
    | n + 1 =>
      let (a, b) := go n
      (b, a + b)
  (go n).1

-- IO monad for effectful computation
def main : IO Unit := do
  for i in List.range 20 do
    IO.println s!"fib({i}) = {fibMemo i}"

The IO monad tracks side effects in the type system. do-notation provides imperative-style sequencing. String interpolation (s!"...") works natively. The language is expressive enough that Lean 4's own compiler is written in Lean 4.

A Lean 4 HTTP Service with Verified Core Logic

For a realistic deployment: a Lean 4 HTTP service with machine-checked invariants on its core computation.

import Std
import Lean

-- Verified prime checker: we prove correctness properties
def isPrime (n : Nat) : Bool :=
  if n < 2 then false
  else if n == 2 then true
  else if n % 2 == 0 then false
  else
    let bound := Nat.sqrt n + 1
    (List.range bound).filter (· >= 2) |>.filter (· % 2 != 0) |>.all (n % · != 0)

-- Theorem: 2 is prime (machine-checked)
theorem two_is_prime : isPrime 2 = true := by rfl

-- Theorem: 1 is not prime (machine-checked)  
theorem one_not_prime : isPrime 1 = false := by rfl

-- Simple HTTP handler
def handleRequest (path : String) : IO String := do
  if path.startsWith "/prime/" then
    let numStr := path.drop "/prime/".length
    match numStr.toNat? with
    | some n =>
      let result := isPrime n
      return s!"{\"number\": {n}, \"isPrime\": {result}}"
    | none =>
      return "{\"error\": \"invalid number\"}"
  else if path == "/health" then
    return "{\"status\": \"ok\"}"
  else
    return "{\"error\": \"not found\"}"

-- TCP server using Lean 4's IO system
def main : IO Unit := do
  IO.println "Lean 4 server starting on port 8080"
  -- In production: use a proper HTTP library
  -- This demonstrates the structure
  let result ← handleRequest "/prime/17"
  IO.println result

The key property: two_is_prime and one_not_prime are theorems — not tests, not documentation, not assertions that might be disabled. They are machine-checked proofs that the isPrime function returns the correct values. Any modification to isPrime that breaks these theorems causes a type error at compile time.

Deploy to Europe with sota.io

Lean 4 applications run on sota.io with a standard Docker container. Create a Dockerfile:

FROM debian:bookworm-slim AS builder

RUN apt-get update && apt-get install -y \
    curl \
    git \
    libgmp-dev \
    && rm -rf /var/lib/apt/lists/*

# Install elan (Lean version manager)
RUN curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | \
    sh -s -- -y --default-toolchain leanprover/lean4:stable

ENV PATH="/root/.elan/bin:${PATH}"

WORKDIR /app
COPY . .

# Build the Lean 4 project
RUN lake build

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y libgmp10 && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY --from=builder /app/.lake/build/bin/ /app/bin/

EXPOSE 8080
CMD ["./bin/server"]

Your lakefile.lean:

import Lake
open Lake DSL

package server where
  name := "server"

lean_exe server where
  root := `Main

Deploy with sota.toml:

[app]
name = "lean4-api"
region = "eu-central"

[build]
dockerfile = "Dockerfile"

[server]
port = 8080

[resources]
memory = "512"
cpu = "1"

Run:

sota deploy

Your Lean 4 service runs in the EU within minutes, on German infrastructure, GDPR-compliant by default.

Why EU Hosting Matters for Lean 4 Workloads

Lean 4 is used for formal verification in safety-critical domains where EU regulation is most stringent.

EU AI Act compliance: Article 13 (transparency) and Article 15 (robustness and accuracy) of the EU AI Act require that high-risk AI systems be verifiable. Machine-checked proofs of correctness properties — exactly what Lean 4 provides — are the strongest form of verification evidence. If you are building AI components subject to the EU AI Act, EU infrastructure is not just convenient: it simplifies compliance with data residency requirements that apply throughout the verification and audit lifecycle.

Medical device software: The EU Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR) impose strict requirements on software in medical devices. Formal verification using tools like Lean 4 produces the audit evidence that MDR/IVDR conformity assessment bodies require. EU-hosted infrastructure keeps audit data in Europe.

Financial system verification: EU financial regulators (EBA, ESMA, ECB) have increasing interest in formally verified components for critical financial infrastructure. Lean 4's capacity to prove properties of cryptographic protocols and data processing pipelines is directly applicable to EU financial compliance.

Research data sovereignty: Mathlib contributors and Lean 4 research groups in EU universities are subject to European research data regulations under Horizon Europe funding. EU-hosted Lean 4 services keep research data, computation logs, and verification artefacts in European jurisdiction.

sota.io runs on German infrastructure — Frankfurt-region servers — with PostgreSQL databases co-located in the same region. No third-country data transfers. No GDPR complications.

Lean 4 in the Formal Verification Ecosystem

Lean 4 occupies a specific position relative to other formal verification tools.

Lean 4 vs. Coq: Coq (developed at INRIA) is the older, more established proof assistant. Lean 4 offers a more integrated programming language experience — you can write executable code and proofs in the same syntax. Lean 4's metaprogramming system makes tactic development more accessible than Coq's OCaml-based plugin system. Mathlib's scope now exceeds Coq's Mathcomp in breadth.

Lean 4 vs. Agda: Agda (Chalmers University) is the proof assistant most used for programming language research. Lean 4 provides better automation (the simp, omega, and decide tactics) and stronger library support through Mathlib. Agda remains preferred for certain type-theoretic research where its dependent types are more flexible. (See the Agda post.)

Lean 4 vs. Idris 2: Idris 2 (Edwin Brady, University of St Andrews) targets practical dependently-typed programming with effects. Lean 4's primary strength is the proof assistant aspect and Mathlib's depth. Idris 2 has better ergonomics for effects-heavy programming. (See the Idris 2 post.)

Lean 4 vs. Isabelle/HOL: Isabelle (Cambridge/TU Munich) is the proof assistant most used in industrial software verification (seL4 microkernel, CompCert compiler). Lean 4's advantage is a unified programming language + proof system. For industrial verification of existing C/Rust code, Isabelle's toolchain is more mature.

European Connections Table

Get Started

# Install sota CLI
npm install -g sota-cli

# Login
sota login

# Deploy your Lean 4 project
cd your-lean4-project
sota deploy

# View logs
sota logs

Your Lean 4 application runs on EU infrastructure with GDPR compliance by default — verified correctness, European data residency.

Start deploying →

See also:

• Deploy Agda to Europe — Formally verified backends with Agda on EU infrastructure
• Deploy Idris 2 to Europe — Dependently typed backends with Quantitative Type Theory on EU infrastructure
• Deploy Haskell to Europe — Haskell functional backends with Servant on EU infrastructure
• Deploy to Europe: All 50 Languages — Complete language deployment guide on EU infrastructure