Architecture

Ideas behind Trellis

Run proven software. Make it fit your company. Keep it working as it changes.

Trellis combines two ideas: malleable software, which makes the transition from using an application to changing it more gradual, and application operators, which package the expertise needed to run it. The audience is a small company that wants its own software without becoming a software company.

Keep the good parts; change what doesn’t fit

An established app contains years of useful decisions about workflows, interfaces and reliability. Reuse those foundations. Start with settings, use extensions where they fit, and change code when the need warrants it. A custom workflow should become part of the app you use—not a conversation you repeat every morning.

The influence is Ink & Switch’s Malleable Software and its argument for gradual customization and communal creation. Trellis’s additional design bet is maintained adaptation: preserve the local difference through upstream upgrades, or explain the incompatibility before changing the installation. Generating a patch is only the beginning.

Reuse the expertise, too

The app definition carries deployment references, supported operations, checks, recovery procedures and guidance for an agent. Installation-specific settings and access remain separate. A new installation or replacement agent should benefit from the same knowledge without inheriting another owner’s credentials or requiring the original conversation.

This draws on Juju charms and the operator pattern. Trellis borrows the principle of application-specific operational knowledge; it does not require every owner to run Kubernetes or replace existing deployment tools.

A useful customization should be reusable: its purpose, upstream version, code difference and tests can travel together. Company data, secrets and authority cannot. Another owner supplies their own settings and permissions. This is a direction for reusable adaptations, not a requirement to build a marketplace before one adaptation works.

Spend less attention, not just less on servers

The default experience is apps you can open, changes you can request and decisions that need you. Routine checks should run without a model and remain quiet when no action is needed. Deeper controls stay available. Measure the cost of ownership in interventions and recovery work as well as infrastructure and model bills.

The influences are calm technology, mixed-initiative interfaces and SRE’s Eliminating Toil. Quiet operation must not conceal missed failures.

Connect the apps without erasing their boundaries

A note can become a project task without rebuilding either application. A connection still needs rules for identity, permissions, retries and deletion. Cambria motivates treating data translation as more than matching field names. A shared context graph can grow from useful connections; it is not a prerequisite for managing an app.

Ownership includes leaving

Keep the application, data, deployment knowledge and local changes usable without the original agent—or Trellis. Export and tested recovery matter. Local-first software informs that ambition, but hosting a server yourself does not automatically give its app offline behavior.

Where the full design lives

Start with Software Worth Keeping: the full argument, operating model, examples and proposed evaluation. Then read Proven applications, maintained adaptations for the source-by-source analysis of malleability, operators, local-first, attention and provenance.

This guide distills those two papers. Their research sources motivate Trellis’s design; they do not establish its performance. For the product experience, see how it works and common questions.