Magnus Opera – Blog

Introducing Starpac: desired-state database delivery

contact@magnusopera.io (Magnus Opera) — Wed, 05 Aug 2026 00:00:00 +0200

Database schemas are easier to reason about when the repository describes the state you want, rather than only the sequence of changes that happened along the way.

Starpac is the home of *pac (pronounced “starpac”), a family of focused desired-state database tools:

pgpac for PostgreSQL;
d1pac for Cloudflare D1 and SQLite.

If you know DACPAC, the mental model will feel familiar: package a declarative database model, compare it to a target, then publish the delta.

Keep the desired schema in Git

A Starpac project points to ordinary SQL files that describe tables, indexes, views, and other database objects as they should exist. The CLI builds those files into a portable package: .pgpkg for pgpac or .d1pkg for d1pac.

The package can then be compared with a live database:

pgpac plan \
 --package out/Application.pgpkg \
 --connection "postgres://user:pass@localhost:5432/appdb"

d1pac plan \
 --package out/Application.d1pkg \
 --database application \
 --script deployment.sql

Instead of maintaining a growing chain of migration scripts, you can read the schema that the application expects today. Starpac works out the operations required to bring the target database to that state.

Review before applying

Planning and applying are separate steps. A plan can be rendered as text, JSON, or SQL, making it suitable for local review and CI automation.

Destructive operations are explicit. If a deployment would remove schema or data, the apply command stops unless the caller deliberately opts in. This keeps the desired-state workflow convenient without hiding consequential changes.

Although pgpac and d1pac share a workflow, each tool retains engine-native behavior. PostgreSQL and D1 are not forced through a generic database abstraction.

Install the tool you need

Both CLIs are available from the Magnus Opera Homebrew tap:

brew tap magnusopera/tap
brew install pgpac

or:

brew tap magnusopera/tap
brew install d1pac

Visit the Starpac website for the pgpac and d1pac quickstarts, command references, and versioned documentation. The project is open source on GitHub.

Introducing Forge

contact@magnusopera.io (Magnus Opera) — Sat, 18 Jul 2026 00:00:00 +0200

Forge is a focused GitHub client for macOS.

It keeps repositories, pull requests, issues, and workflows together in a fast, keyboard-friendly three-pane workspace—so you can move through the work without building a maze of browser tabs.

Forge is local-only and open source. Your GitHub token stays protected on your Mac, and GitHub remains the source of truth.

Install the Apple Silicon build with Homebrew:

brew tap magnusopera/tap
brew install forge

Download Forge or view the source on GitHub.

FScript: a strongly typed language designed to be embedded

contact@magnusopera.io (Magnus Opera) — Fri, 17 Jul 2026 00:00:00 +0000

Terrabuild’s extensions are powered by FScript, a small, open-source language built at Magnus Opera. We created it for a specific reason: applications sometimes need logic that can evolve independently, without giving up the guarantees and boundaries of the host system.

FScript is not only a command-line scripting tool. It is an embeddable language runtime for .NET and JavaScript applications. A host can load a script in-process, type-check it, inspect its exported functions, and invoke them by name. No sidecar service or RPC layer is required.

ML-style, with strong static typing

FScript belongs to the ML family of languages and will feel familiar to F# and OCaml developers. Its language model includes:

immutable bindings and expression-oriented code;
records and discriminated unions;
options, lists, tuples, and maps;
functions, pipelines, and pattern matching;
Hindley–Milner type inference.

The last point matters. FScript is strongly and statically typed, but most types do not need to be written explicitly. The language infers them and checks the program before evaluation. Type annotations remain available wherever an interface should be made explicit.

Here is the pricing example from the FScript home page:

type Customer =
 { Name: string
 Plan: string
 Seats: int }

[<export>] let quote (customer: Customer) =
 let basePrice =
 match customer.Plan with
 | "scale" -> 29
 | "team" -> 19
 | _ -> 9

 basePrice * customer.Seats

The Customer record defines the input contract. Pattern matching makes the pricing rule explicit, and the type checker infers that quote returns an integer. The [<export>] annotation makes the function visible to the embedding host; everything else stays internal to the script.

This is the balance FScript aims for: concise enough for rules and automation, while retaining the structure expected from application code.

The host stays in control

Embedding a language is also about deciding what scripts are allowed to do.

FScript uses a capability-based model. The core language has no ambient access to the filesystem, network, database, or process environment. The host explicitly registers typed external functions, and scripts can use only the capabilities they receive.

The boundary works in both directions:

the host defines typed functions available to scripts;
scripts expose only bindings marked with [<export>];
scripts are parsed and type-checked before execution;
the host controls source loading, imports, timeouts, and operational limits.

This makes FScript suitable for product rules, workflows, build integrations, and other extension points where flexibility must remain reviewable and constrained.

Why Terrabuild uses FScript

A Terrabuild extension translates a target action such as build, test, or publish into the shell operations that Terrabuild schedules. Built-in extensions for .NET, npm, pnpm, Docker, Terraform, and other tools are FScript programs, and workspaces can provide their own .fss extensions without recompiling Terrabuild.

The language and the host protocol complement each other:

FScript provides typed records, unions, options, functions, and pattern matching.
Terrabuild provides typed build contexts and extension contracts.
The extension returns data describing commands instead of running arbitrary processes directly.
Terrabuild remains responsible for scheduling, containers, caching, artifacts, and failure handling.

Because the protocol is strongly typed, an extension’s inputs and outputs are checked when the script is loaded. Because capabilities are host-controlled, Terrabuild can restrict filesystem access and omit functions that do not fit deterministic graph evaluation.

The result is an extension system that is easier to read and change than compiled plugins, without falling back to unstructured shell scripting.

Explore FScript

FScript can be used as a standalone CLI, embedded through NuGet packages, or loaded in a JavaScript application through @magnusopera/fscript.

You can try FScript in the browser, read the language manual, or explore the project on GitHub.

Terrabuild release status: from RC1 to 0.195

contact@magnusopera.io (Magnus Opera) — Fri, 17 Jul 2026 00:00:00 +0000

Terrabuild RC1 was announced on March 4, 2026 with version 0.189.22. Four months later, the latest stable release is 0.195.10, published on July 16.

That represents six minor release lines and a steady progression from a release candidate to a more mature build platform. The changes go well beyond maintenance: Terrabuild now has stronger cache correctness, richer build data, a simpler extension model, clearer execution semantics, and new tools for automation.

More reliable artifacts and caching

Releases 0.190 through 0.192 focused heavily on correctness.

Batched restores now reuse existing artifacts instead of publishing them again.
Cache summaries no longer advertise output archives that were never created.
Repository identities are normalized across local checkouts, GitHub Actions, and Git worktrees, keeping project and graph hashes stable.
Remote-cache integration tests now exercise a complete .NET build through Docker, including restoring a project reference on a clean worker.

These changes make shared caching more predictable and reduce unnecessary transfers and rebuilds.

Better visibility and machine-readable reports

Terrabuild now sends richer build-graph and artifact metadata to Insights, including stable project identities, project and target hashes, and execution timestamps.

Version 0.195 also introduced JSON reports for both execution and impact analysis:

terrabuild run --out build-report.json
terrabuild impact --base <sha> --out impact-report.json

This makes Terrabuild easier to integrate with CI gates, reporting pipelines, and other engineering tools. Impact analysis was also refined to compare source graphs independently from the execution-specific graph used by run.

FScript becomes the extension model

The transition announced with RC1 is now complete. Terrabuild extensions use FScript .fss scripts, and the legacy compiled F# .fsx compatibility layer has been removed.

The built-in extensions now live alongside Terrabuild as scripts, the standalone @fscript extension is available for custom automation, and dependency resolution can explicitly use workspace paths or extension scopes. The embedded FScript runtime has continued to evolve and reaches version 0.75.0 in Terrabuild 0.195.10.

The result is a smaller, more consistent extension surface with clearer security boundaries.

A clearer execution model

The runtime now treats Docker, Podman, and host execution as explicit engine choices. Workspace configuration is authoritative, while the console and expressions expose the selected engine consistently.

The graph pipeline has also been separated more carefully into source analysis and execution resolution. This improves impact calculations, restores execution-specific batch clustering, and provides better diagnostics for dependency cycles and invalid cached summaries.

For day-to-day maintenance, the new command below removes old entries from the local cache while active entries have their access time refreshed automatically:

terrabuild prune <days>

Documentation and platform updates

Terrabuild’s documentation now ships with the source repository and is versioned with stable releases. The website exposes both the current preview documentation and snapshots for stable versions.

The recent releases also include:

hardened cache archive extraction;
improved macOS signing and notarization;
macOS arm64 as the supported Apple binary;
security updates across the website and UI dependencies;
clearer errors when Terrabuild is run outside a Git repository.

What is next: build phases

The current preview line, 0.196.3-next, introduces workspace-declared build phases. Phases provide whole-phase success barriers, keep batches isolated by phase, and can be displayed as grouped blocks in the interactive graph console.

This work is still on the -next channel and is not part of the latest stable release. It points toward a clearer way to model broad delivery stages without replacing the target-level dependency graph.

Try the latest release

The current stable version is 0.195.10. Release notes and binaries are available on GitHub, and the latest documentation is available at terrabuild.io.

Questions or feedback? Contact us at contact@magnusopera.io.