Pyrite ITMenu Download the alpha
01 / Technology

Go, PocketBase, SQLite. Open at every layer.

We chose open, established and well-documented technologies so you can decide how and where to run your apps. Apps remain PocketBase projects, data stays in SQLite files, and moving the engine takes a folder copy.

01.1 · the engine

Go

Go is an open-source language introduced by Google in 2009 for building reliable network software. Docker and Kubernetes are also written in Go.

For Pyrite, that means one executable, with no separate runtime, dependencies or installer. Copy the folder and run it. The same source code already compiles for Linux.

  • One executable with no dependencies
  • Fast and light on memory
  • The same source for Windows and Linux
  • Open source under a BSD license
01.2 · the apps

PocketBase

PocketBase is an MIT-licensed, open-source backend written in Go. One program provides a database, user authentication, file storage, REST and realtime APIs, and an admin dashboard.

Pyrite uses PocketBase twice: as the foundation for the engine and as a separate instance for every app that stores data. App logic lives in readable, portable JavaScript hooks and migrations. The PocketBase version is fixed and tested, currently 0.40.6: a new version arrives only with a Pyrite update.

  • Database, users, files and APIs in one program
  • Realtime updates
  • App logic in JavaScript
  • Open source under the MIT license
01.3 · the data

SQLite

SQLite stores an entire database in one file. The application reads and writes the file directly, with full transaction support. There's no database server to install or maintain. If the power fails during a write, the data stays consistent.

SQLite is the world's most widely used database, found in smartphones and web browsers. Its authors have committed to keeping the file format compatible through 2050, and the US Library of Congress lists it among the recommended formats for long-term data preservation.

For Pyrite users, backups amount to copying files, and dozens of tools can open the data even without Pyrite. SQLite handles one write at a time. That suits most web apps, though high-volume online services can have heavier write workloads than it is designed for.

  • One database, one file
  • Full transactions, even if power fails
  • File format compatibility through 2050
  • Public-domain code

Apps communicate over HTTP using JSON, logic is written in JavaScript, and code and data live in ordinary files on disk.

02 / Portability

You own your data. Always.

With this stack, moving your data can be as simple as copying a file.

02.1 / A file

One app's data, one file.

Every app that stores data keeps its records in a SQLite database inside its data folder. There's no database server to query or export from.

02.2 / Download

Download a backup whenever you need one.

Download an app backup from the console. It contains the database and files that people have uploaded. You can do it yourself, in standard formats.

02.3 / Run it elsewhere

Open it in another PocketBase instance.

Put the data into a PocketBase instance running the same version, currently 0.40.6. Your collections, records, files and users are all there.

02.4 / Moving out

When you leave, the app goes with you.

When you choose to leave, we'll provide a complete package: your app repackaged as a standalone PocketBase project, with its pages, rules, data and sign-in.

02.5 / Your choice

Stay for as long as it works for you.

We want to earn your trust by using open technology, keeping data accessible and making sure you can always move your apps elsewhere.

03 / Sovereignty

European digital sovereignty. Built into the software.

You can inspect the source code, choose where your SQLite files live and run the engine on your own servers, even offline. You don't need an account with a hosting provider to run your apps.

If you ever want to change course, the way out is always open: your apps stay PocketBase projects and your data stays in SQLite files. Staying or leaving is your choice, not a dependency.

04 / Updates

Atomic updates for apps and the engine.

Code and data live in separate folders. The engine stages a new version alongside the running one and switches only after every check passes.

04.1Versions side by side
The engine unpacks the new version in a separate folder while the current version continues serving users.
04.2Inspection and testing
The engine checks the package and code, much like scanning a container image. It tests migrations on a copy of the data, starts the new version in a test run and checks its health.
04.3An all-or-nothing switch
Once the checks pass, the engine backs up the app, swaps the code, runs migrations and restarts it. If a step fails, it restores the previous version and its data.

This applies to hosted apps and to the engine itself, which saves a copy of its registry before every update.

05 / The standard

A standard to build on. Portable and open source.

We wrote a skill for AI agents: a public document in English and Italian that the agent reads before writing any code. The result is a standard PocketBase app with security rules in place, ready to run on the engine.

05.1Structure
A folder containing the app.json manifest, migrations, hooks and pages. It uses the same layout as any other PocketBase project.
05.2Users and roles
Identity comes from the engine's directory, so there's no need to write sign-in or registration pages. The manifest declares the roles.
05.3Data rules
Record-level access rules are mandatory and run on the server. Hiding a button in the interface wouldn't protect the data.
05.4Scripts and tools
JavaScript hooks and migrations run in the app's isolated environment. Engine tools handle heavier tasks such as importing data from Excel.
05.5Languages and testing
Write code in English, supply app text in the languages people need and test with a low-privilege role before delivery.
05.6Delivery
Deliver a ZIP ready for “Upload app” along with plain-language delivery notes for the administrator. Updates use the same format.