AWF — a website as a single executable
An application server where a website, portal or API is written in Python, Lua or TCL, and everything underneath — networking, protocols, encryption, cluster — is the compiled AWH core with no third-party dependencies at all.
Today a web portal is a stack of twenty parts
- nginx or Apache in front, a separate application process behind — two configurations, two logs, two points of failure.
- An interpreter with a package manager and dozens of dependencies — each with its own version, vulnerabilities and update pace.
- Separate services for queues, cache, search, scheduling — four more daemons to monitor.
- Containers, just to make all of it reproducible.
What a developer needs
One tool: write a handler, get a working site. Deploying the same thing on Windows, ARM or BSD should be the same command, not a separate project.
One executable — the whole platform
AWF installs as a single file and is at once a web server, a script runtime, a process cluster and a set of thirty ready-made modules.
1 · Request
HTTP/1.1, HTTP/2, HTTP/3 or WebSocket arrives at the core and is parsed by compiled code.
2 · Script
The core finds the script by domain name; a handler in Python, Lua or TCL receives the parsed request.
3 · Response
Compression, encryption and delivery happen in the core again; the script doesn't think about them.
The architecture is not invented from zero: a script layer with mirrored modules, domain binding, queues and script encryption has run for years in our closed project, where user code executes on the server under load.
Three languages — three different reasons
Lua · low entry barrier
One of the simplest languages in the world: its whole description fits in a booklet and the syntax takes a day. A junior developer can learn on the job. The lightest interpreter — for hot paths.
TCL · command of the system
A language grown into the OS shell: it naturally drives the system and external programs. A site becomes a control panel for servers and hardware; telecom and CAD legacy moves over without rewriting.
Python · the whole package world
The most popular language with full pip support and no restrictions. Neural networks, data processing, computer vision — right in a page handler, without a scatter of separate services.
All three get a mirrored module set: web, ws, tcp, dns, ntp, fs, regexp, csv, hash, syslog, timer, hnsw, bloom, lev and more — with the same method names and behaviour.
Modules in different languages work as one
Each module is written in the language that suits it, and any module calls any other by function name without knowing what language it is written in. The platform keeps a shared function registry and delivers the call to the right process.
# TCL · maintenance catalog call "reindex" $ids
-- Lua · catalogue ai:call("embed", text)
# Python · smart search shop.call("price", sku)
The team doesn't argue about languages, a module can be rewritten in another language without touching the rest, and a module library fits any project. The snippets illustrate the planned interface; the call form is settled when the script layer is ported.
The languages are part of the project, not dependencies
| Language | Version | How it is built |
|---|---|---|
| Python | 3.13 | profile-guided optimisation (PGO), ThinLTO, -O3 |
| Lua | 5.4 | seven platform patches: ARM, FreeBSD, Solaris, Windows, Windows ARM |
| TCL | main | static 64-bit build |
Distributions don't build like this: the system Python is built for compatibility, without PGO or link-time optimisation. pip packages are installed by the built-in interpreter into the site's own directory — the whole library world is available, but it lives inside the platform, not in the client's system.
Processes instead of threads
AWF is built on the AWH process cluster, which works on Windows too: the master accepts connections and hands them to workers.
- Site isolation. A neighbour's script can neither read your memory nor crash your process.
- Crash restart. The cluster brings a dead process back; the site keeps answering.
- No Python ceiling. The global interpreter lock lives inside a process — eight processes, eight cores.
- Memory under control. A leak in a script is confined to its process and cleared by its restart.
- Zero-downtime updates. Workers are replaced one by one while the master keeps accepting.
- One install — hundreds of sites, each in its own process with its own rights, limits and log.
The project ships to the client as one application
The site's scripts are encrypted and packed together with the platform. The client receives a working web project as a single application — without the source code and without insight into how it is built.
- Source stays home: code is sealed with AES-GCM, the key is split, launch is checked against a licence key.
- Architecture stays hidden: from outside there is one executable.
- Closed environments: no access to our servers and no internet needed.
What this changes
A studio sells the result while its know-how stays with the author. A product company installs a boxed version on client servers without handing over the product. A catalogue of ready solutions — forum, cart, account area — without leaking source.
Where AWF is stronger than the usual stacks
| AWF | PHP + nginx | Node.js | Python + Django | |
|---|---|---|---|---|
| Parts to ship | one | two or more | two or more | three or more |
| Core external dependencies | zero | dozens | hundreds | dozens |
| HTTP/3 in-house | yes | via a front server | partly | via a front server |
| Languages for logic | three | one | one | one |
| Process isolation of sites | built in | external | external | external |
| GOST included | yes | external module | no | external module |
| Source protection on delivery | built in | no | no | no |
| Ecosystem maturity | just starting | huge | huge | huge |
The last row is honest: we don't win on the number of ready libraries. We win where a stack has to be deployed, isolated and run by a small team — on your own servers, on an unusual system, under load.
Three stages
Stage 1 · Platform core
- script layer on AWH v5
- process cluster
- domain routing and static files
- sessions, forms, uploads
Stage 2 · Product
- site control panel
- per-site limits and logs
- documentation and examples in three languages
Stage 3 · Ecosystem
- script catalogue with licensing
- templates: portal, shop, knowledge base
- smart features on the vector index