Template to platform
Start with a GitHub template
Choose embedded or remote-fleet. Both repositories wire in Unified Field products, and you decide what stays in your application.Embedded or remote-fleetUnified Field platformYour application
Why Unified Field
Why Unified Field
Choose the embedded or remote-fleet GitHub template. Both start with the same platform products, account system, product shell, and application patterns; keep what fits and replace what does not.Accounts and a first-run path
Lepton provides sign-in and account settings. The welcome page and route-aware spotlight tours give new users a way into the applications they can access.Transparent data path
Valence keeps typed models and access policies together, and the schema and policy code remain open to inspection. Applications can show what data they use and why, while the schema records who may read or change each field and under which conditions.User context follows the work
Higgs builds user-scoped Valence in a server function. When that request schedules work or publishes an event, Boson, Chronon, and Photon rebuild the captured actor through the same factory instead of silently switching to System access.Search, notifications, and history
Workspace search and notifications are part of the signed-in shell. Record-history views can be composed into embedded and zone applications; that UI is not mounted on this public host.Live UI and deployment
Photon keeps product views current. The embedded template runs the platform in one process; remote-fleet separates services and can add Gluon and Nucleus for cloud placement and data-service control.Job definitions
Define Boson tasks and Chronon scripts with Rust macros. The same handler contracts run in-process or on remote workers, and their operator applications are being prepared for public release.Valence schemaValence
Schema DSL + builder backends
use std::sync::Arc;
use valence::{
Database, DatabaseFromEngine, FieldType, InMemoryBackend, Valence, MEM_ENGINE_ID,
valence_schema,
};
const COUNTER_DB: DatabaseFromEngine = Database::from_engine("default", MEM_ENGINE_ID);
valence_schema! {
Counter {
table: "counter",
version: "0.1.0",
description: "Simple counter",
database: COUNTER_DB,
fields: [
id: { r#type: FieldType::String, primary_key: true, required: true },
value: { r#type: FieldType::Integer, required: true },
],
}
}
let valence = Valence::builder()
.add_backend("default", Arc::new(InMemoryBackend::new()))
.build()?;Boson taskBoson
Typed #[task] + enqueue
use std::sync::Arc;
use boson::{
configure, task, Boson, ExecutionContext, JsonExecutionContextFactory,
MemQueueBackend,
};
#[task(name = "process_order")]
async fn process_order(
ctx: Box<dyn ExecutionContext>,
order_id: String,
amount_cents: u64,
) -> boson_core::Result<()> {
tracing::info!(actor = ctx.label(), %order_id, amount_cents);
Ok(())
}
#[tokio::main]
async fn main() -> anyhow::Result<()> {
let boson = Boson::builder()
.queue_backend(Arc::new(MemQueueBackend::new()))
.execution_context_factory(JsonExecutionContextFactory)
.auto_registry()
.build()?;
configure(boson);
ProcessOrder::send_with(
serde_json::json!({"System": {"operation": "checkout"}}),
ProcessOrderParams {
order_id: "ord-42".into(),
amount_cents: 9900,
},
)
.await?;
Ok(())
}Chronon scriptChronon
Cron job + typed #[chronon::script]
use std::sync::Arc;
use chronon::prelude::*;
use chronon::InMemorySchedulerStore;
#[chronon::script(name = "nightly_cleanup")]
async fn nightly_cleanup(
ctx: Box<dyn ScriptContext>,
retention_days: u32,
) -> chronon::Result<()> {
println!("{}: retaining {retention_days} days", ctx.label());
Ok(())
}
#[tokio::main]
async fn main() -> chronon::Result<()> {
let chronon = Chronon::builder()
.scheduler_store(Arc::new(InMemorySchedulerStore::new()))
.context_factory(Arc::new(JsonScriptContextFactory))
.embedded()
.auto_registry()
.build()?;
let mut nightly = Job::new("nightly-schedule", "nightly_cleanup");
nightly.schedule_kind = ScheduleKind::Cron;
nightly.cron_expr = Some("0 2 * * *".into());
nightly.timezone = Some("UTC".into());
nightly.params_json = serde_json::json!({ "retention_days": 7 });
chronon.coordinator_service().upsert_job(nightly).await?;
chronon.run().await
}Why benchmarks matter here
This table is the same completed-work slice as Resources: embedded SQLite and remote fleet, measured on AWS. A row appears only after a passing campaign. Scale-out is observed through four application nodes.AWS performance study
| Product | Workload | Profile | Completed work | p95 | Tested scale |
|---|---|---|---|---|---|
| Chronon | Due-job burst with a five-minute cohort | Embedded SQLite | 1.7 completed jobs/s | 84 s | 1 host |
| Chronon | Due-job burst with a five-minute cohort | Remote fleet | 2.4 completed jobs/s | 68 s | 4 worker hosts |
| Boson | Bounded job completion | Embedded SQLite | 117 completed jobs/s | not reported | 1 host |
| Boson | Bounded job completion | Remote fleet | 199 completed jobs/s | not reported | 4 worker hosts |
| Photon | Durable publish, one subscriber | Embedded SQLite | 100 completed publishes/s | 6.3 ms | 1 host |
| Photon | Durable publish, one subscriber | Remote fleet | 2,250 completed publishes/s | 1.7 ms | 4 app hosts |
| Photon | Durable publish, four-subscriber fanout | Embedded SQLite | 500 completed publishes/s | 6.0 ms | 1 host |
| Photon | Durable publish, four-subscriber fanout | Remote fleet | 3,250 completed publishes/s | 1.8 ms | 4 app hosts |
| Spectra | Durable write then read-your-write | Embedded SQLite | 80 completed writes/s | 4.3 ms | 1 host |
| Spectra | Durable write then read-your-write | Remote fleet | 100,000 completed writes/s | 36 s | 4 writer hosts |
| Valence | Hybrid lookup after a write | Embedded SQLite | 5,740 completed lookups/s | 7.8 ms | 1 host |
| Valence | Hybrid lookup after a write | Remote fleet | 17,715 completed lookups/s | 40 ms | 4 app hosts |