2026-04-28·9 min read·sota.io team

Deploy Common Lisp to Europe — EU Hosting for Hunchentoot & SBCL Backends in 2026

Common Lisp is the language that European AI researchers used when they built the first expert systems, the language that European hackers used when they wrote the web servers that predated nginx, and the language that a Hamburg-based mathematician chose when he decided to give the Common Lisp world something it had been missing: a real web framework. The language was invented in the United States in the 1980s, but the infrastructure that makes Common Lisp practical for web development in 2026 was built in Europe.

The web stack that most Common Lisp developers reach for today — Hunchentoot as the HTTP server, cl-ppcre for regular expressions, cl-who or Djula for templating — was largely created by a single German programmer who wrote code because existing solutions annoyed him. Edmund Weitz, based in Hamburg, has produced more practically useful Common Lisp infrastructure than any other European contributor. He is also the author of Common Lisp Recipes, the book that working Lisp programmers keep open when they need to get something done.

Europe's Contributions to Common Lisp

The Common Lisp standard (ANSI X3.226-1994) was produced by the American National Standards Institute, but its European adoption and infrastructure development created a rich ecosystem that operates independently of American tooling.

Edmund Weitz 🇩🇪 (Hamburg, Germany) is the author of:

Hunchentoot — the standard Common Lisp web server, used by virtually every production CL web application. Hunchentoot handles HTTP/HTTPS, cookies, sessions, and dispatching. It is the foundation on which frameworks like Caveman2 and Easy-Routes are built.
cl-ppcre — a portable Perl-compatible regular expression library. It is the regex library for Common Lisp, imported by hundreds of other libraries and used in every production CL system.
cl-who — an HTML generation library that lets you write HTML as S-expressions. The style that influenced a generation of Lisp web templates.
Drakma — an HTTP client library, the curl of Common Lisp.
CL-Base64, CL-FAD, CL-STORE, and many others — Weitz has been quietly building Common Lisp infrastructure in Hamburg for over twenty years.

His work at Hamburg is not institutional — he writes code because Common Lisp needs it and he knows how to write it well. The European Lisp community runs on infrastructure he built.

Bruno Haible 🇩🇪 (Karlsruhe, Germany) is the primary author and long-time maintainer of CLISP, one of the most widely-used Common Lisp implementations. CLISP was originally developed at the Karlsruhe Institute of Technology (KIT) in the early 1990s by Michael Stoll and Bruno Haible. KIT is one of Germany's premier technical universities — the institution where Heinrich Hertz studied electromagnetics and where the German tradition of applied scientific computing runs deep. CLISP was notable for its portability, its detailed error messages, and its acceptance of a bytecode compilation model that made it accessible on modest hardware. For most of the 1990s and 2000s, CLISP was the Common Lisp that European students and researchers downloaded first.

Haible continued maintaining CLISP alongside his work on GNU libunicode and other open-source infrastructure. His contribution to Common Lisp accessibility in Europe cannot be overstated — KIT's implementation was how an entire generation of European computer science students first encountered Lisp.

ECL (Embeddable Common Lisp) is maintained by Juan José García Ripoll 🇪🇸 (Spain, formerly at the Max Planck Institute for Quantum Optics in Garching, Germany) and Daniel Kochmański 🇵🇱 (Poland). ECL compiles Common Lisp to C and produces native binaries or shared libraries, making it the implementation of choice when Common Lisp needs to be embedded in larger systems. The Spanish-Polish collaboration on ECL represents the pan-European nature of Common Lisp infrastructure development — neither contributor is based in a single institutional centre, yet they maintain one of the three most important CL implementations.

The European Lisp Symposium (ELS) has been held annually since 2008, rotating through European cities including Paris, Copenhagen, Brussels, Marbella, Zaragoza, London, Linz, and Genova. ELS is the main academic and practitioner conference for the Common Lisp, Scheme, and Emacs Lisp communities. Papers on Hunchentoot optimisation, SBCL improvements, and ECL embedding techniques have all appeared at ELS. The conference's existence — and its survival through fifteen years of Lisp being declared dead — reflects the European programming community's genuine investment in the language.

INRIA 🇫🇷 (Paris and other French sites) used Common Lisp extensively in AI research through the 1980s and 1990s. The REFINE and early ACACIA knowledge representation systems, AI planning research, and theorem proving work at French universities ran on Common Lisp. While INRIA has largely moved to OCaml for new systems (a language also developed at INRIA — see our OCaml post), the institutional knowledge that Common Lisp produced in France contributed to the European AI research tradition.

Common Lisp in Production in 2026

Common Lisp is a genuinely practical language for backend web development. It is not fashionable, which means the developers who use it in production have chosen it deliberately — for its performance characteristics, its interactive development model, or its macro system.

Performance: SBCL (Steel Bank Common Lisp) compiles to native machine code with quality comparable to a C compiler for numerically-intensive code. Common Lisp web services can handle thousands of requests per second on modest hardware. The language is garbage-collected, but SBCL's GC is low-latency for typical web workloads.

Interactive development: The Common Lisp REPL is not like a Python REPL. You can redefine functions in a running server without restarting it. You can connect to a running production process with SLIME, inspect its state, and fix a bug by redefining a function — the server continues serving requests through the redefinition. This is what Lisp programmers mean when they say "image-based development." For teams that run long-running computation services, the ability to update logic without restart is operationally significant.

The macro system: Common Lisp macros are code transformations that run at compile time. They are not string templates or preprocessors — they transform Lisp data structures into other Lisp data structures before compilation. For domain-specific languages, query builders, and configuration DSLs, Common Lisp macros produce solutions that are impossible in most other languages.

Quicklisp: The de-facto package manager for Common Lisp, providing access to over 2,000 libraries. While Quicklisp's infrastructure is American, the libraries it distributes include substantial European authorship — Weitz's libraries alone represent a significant fraction of the most-downloaded packages.

Building a Common Lisp HTTP Backend

The standard production stack for a Common Lisp web backend in 2026 is SBCL as the runtime, Hunchentoot as the HTTP server, and Postmodern or cl-dbi for PostgreSQL access.

Project Structure

src/
  main.lisp
  api.lisp
  db.lisp
Dockerfile
sota.yaml

src/main.lisp — Server entry point

(defpackage :myapp
  (:use :cl :hunchentoot))

(in-package :myapp)

;; Define the acceptor (HTTP server)
(defvar *server*
  (make-instance 'easy-acceptor
                 :port (parse-integer (or (uiop:getenv "PORT") "8080"))
                 :access-log-destination *standard-output*
                 :message-log-destination *standard-output*))

;; Health check endpoint
(define-easy-handler (health :uri "/health") ()
  (setf (content-type*) "application/json")
  "{\"status\":\"ok\"}")

;; JSON API endpoint
(define-easy-handler (api-users :uri "/api/users") ()
  (setf (content-type*) "application/json")
  (jonathan:to-json
    (list :|users| (db:list-users))))

(defun main ()
  (db:init)
  (start *server*)
  (format t "Server running on port ~a~%"
          (acceptor-port *server*))
  ;; Keep the process alive
  (loop (sleep 60)))

src/db.lisp — PostgreSQL with Postmodern

(defpackage :myapp.db
  (:use :cl :postmodern)
  (:nicknames :db))

(in-package :myapp.db)

(defun init ()
  (connect-toplevel
    (uiop:getenv "DB_NAME")
    (uiop:getenv "DB_USER")
    (uiop:getenv "DB_PASSWORD")
    (or (uiop:getenv "DB_HOST") "localhost")))

(defun list-users ()
  (query (:select :id :email :created-at
          :from 'users
          :order-by (:desc :created-at)
          :limit 100)
         :plists))

(defun create-user (email)
  (with-transaction ()
    (query (:insert-into 'users
            :set 'email email
            'created-at (local-time:now))
           :none)))

src/api.lisp — Route handlers

(defpackage :myapp.api
  (:use :cl :hunchentoot))

(in-package :myapp.api)

(define-easy-handler (create-user-handler
                       :uri "/api/users"
                       :request-type :post) ()
  (setf (content-type*) "application/json")
  (let* ((body (hunchentoot:raw-post-data :force-text t))
         (data (jonathan:parse body))
         (email (getf data :|email|)))
    (if email
      (progn
        (db:create-user email)
        (setf (return-code*) 201)
        "{\"created\":true}")
      (progn
        (setf (return-code*) 400)
        "{\"error\":\"email required\"}"))))

Dockerfile

FROM sbcl:2.4.0 AS builder

WORKDIR /app
COPY . .

# Install Quicklisp and dependencies
RUN sbcl --non-interactive \
    --eval "(progn \
      (load \"quicklisp.lisp\") \
      (quicklisp-quickstart:install :path \"/ql/\") \
      (ql:quickload '(:hunchentoot :postmodern :jonathan :local-time)) \
      (quit))"

# Build the binary
RUN sbcl --non-interactive \
    --eval "(progn \
      (push \"/ql/\" asdf:*central-registry*) \
      (ql:quickload :myapp) \
      (sb-ext:save-lisp-and-die \"/app/server\" \
        :toplevel #'myapp:main \
        :executable t \
        :compression t))"

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y libssl3 && rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/server /usr/local/bin/server
CMD ["/usr/local/bin/server"]

sota.yaml — Deploy to EU servers

name: myapp-lisp
runtime: docker
region: eu-central
resources:
  memory: 256Mi
  cpu: 0.25
env:
  - PORT=8080
  - DB_HOST=${SOTA_DB_HOST}
  - DB_NAME=${SOTA_DB_NAME}
  - DB_USER=${SOTA_DB_USER}
  - DB_PASSWORD=${SOTA_DB_PASSWORD}

Deploying to sota.io

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

# Login and deploy
sota login
sota deploy

# View logs
sota logs --follow

Your Common Lisp service is running on EU infrastructure — GDPR-compliant by default, PostgreSQL managed, no DevOps required.

Performance Comparison

SBCL-compiled Common Lisp performs comparably to Go and Java for typical web API workloads:

Runtime	Requests/sec	Latency p99	Memory (idle)
SBCL 2.4 (Hunchentoot)	~18,000	4ms	45MB
Go 1.22 (net/http)	~55,000	2ms	8MB
JVM 21 (Spring Boot)	~22,000	6ms	280MB
Node.js 22 (Fastify)	~48,000	3ms	90MB
Python 3.12 (FastAPI)	~8,000	12ms	65MB

SBCL is slower than Go for raw request throughput, but faster than Python and competitive with Java. For the use cases where teams choose Common Lisp — complex business logic, AI inference, knowledge base queries — throughput per request matters less than latency per operation, and here SBCL's native compilation excels.

Why EU Hosting Matters for Common Lisp Services

Common Lisp is used in production by European financial institutions, AI research groups, and teams maintaining long-running systems where the cost of rewriting outweighs the social cost of maintaining Lisp expertise. These are exactly the workloads where GDPR compliance and EU data residency matter most.

Financial services in the EU — a common Common Lisp deployment target, given the language's historical use in trading systems and risk models — are subject to strict data residency requirements under GDPR and sector-specific regulation. Hosting on US infrastructure creates compliance overhead that EU-native hosting eliminates.

sota.io runs in the EU by default. Your Common Lisp backends — Hunchentoot servers, long-running SBCL images, PostgreSQL-connected services — run on European infrastructure, subject to European law, operated by a European company.

Getting Started

Deploy your first Common Lisp backend to EU servers in minutes:

# Clone a starter template
git clone https://github.com/sota-io/examples common-lisp-starter
cd common-lisp-starter/common-lisp-hunchentoot

# Deploy
sota deploy

No containers to configure, no Kubernetes to learn. Your Hunchentoot server is running in the EU in under three minutes.