Start with the current SDK: Follow the Quickstart to install the tools and create your first application. Historical preview evidence and limits remain available for reference.
One greenhouse.
An application you can change.
A greenhouse needs to measure its climate, control a fan, and show what is happening. Later, you will want to change how it responds.
Micros makes those jobs native services that you compose into an application. The resident base provides the kernel, platform support, and management facilities that load and manage them. Application changes can follow their own update path.
Design example: three proposed greenhouse services, used to explain Micros. The greenhouse implementation and readings below are illustrative.
Three services. One shared kernel.
Start with three jobs: Climate sensor measures conditions, Fan controller applies the ventilation policy, and Status display explains the result. Each service instance runs its lifecycle hooks and callbacks on one worker.
One service model, across different controllers
Shared kernel code · a separate native build for each target
The service ABI connects compiled code. The Application Binary Interface defines lifecycle hooks and the kernel functions a service can call. Services compile separately; admission checks their target and ABI compatibility. The current ABI is experimental.
The platform interface connects the kernel to hardware. Each adapter provides tasks, time, memory, and supported hardware operations. Shared kernel source gets a target-specific build. Service binaries and required peripherals must also match the target.
Native services have no enforced memory isolation. A fault can affect other services or management, and a stalled hook can require whole-runtime recovery.
The greenhouse warms. The services respond.
The workers now need to exchange information. Climate sensor publishes a reading. Fan controller decides whether to ventilate and publishes its own status. Status display brings both messages together.
Follow the information through the application
Three services · two typed channels
Each reader advances independently. Reading a message does not remove it for another service. The display can read climate and fan status at its own pace.
latest channels: each retains the current value, so a slow display may skip intermediate states. The two messages can arrive at different times; the display should use timestamps to check their freshness.Choose retention for the information. Current temperature suits a latest-value channel. A history of transitions needs a bounded stream and explicit handling of missed messages. Successful publication alone does not establish that another service acted.
One TOML. Three services. One application.
Those connections are application choices. An application TOML selects reusable service definitions, supplies settings and budgets, and binds ports to channels. Here is how the greenhouse's three jobs fit together.
Read the file beside the application it describes
applications/greenhouse.toml · illustrative excerpt
[services.climate]
manifest = "../services/climate/service.toml"
memory = { arena = "RAM", stack_bytes = 2048 }
publications.reading = { channel = "climate" }Select the implementation and publish readings to the climate channel.
[services.fan]
manifest = "../services/fan/service.toml"
memory = { arena = "RAM", stack_bytes = 2048 }
config = { start_celsius = 28 }
subscriptions.reading = { channel = "climate" }
publications.status = { channel = "fan_status" }Use the same reading channel, set the ventilation threshold, and publish fan status.
[services.display]
manifest = "../services/display/service.toml"
memory = { arena = "RAM", stack_bytes = 2048 }
subscriptions.reading = { channel = "climate" }
subscriptions.fan = { channel = "fan_status" }Subscribe to both channels. The bindings match the two incoming arrows above.
climate and fan_status refer to declarations for climate.reading and fan.status. The full design includes those declarations and schemas. The shown budgets are illustrative; implementations must be sized and validated.One file assembles existing services. Each service's manifest describes its implementation and setting schema. A board file owns wiring; a deployment selects the board, application, and device. The application file brings the software together.
Explore the complete TOML design and try offline composition →
Start the fan earlier. Keep the resident base.
Now suppose the greenhouse should ventilate sooner. Change Fan controller's startup setting from 28°C to 26°C, then prepare a new application selection. The resident base stays in place; on the normal ESP32 service-update path, the application graph pauses for staging.
start_celsius = 28→start_celsius = 26Follow the changed application through deployment
ESP32 service update · equal-width phases, not elapsed time
All three greenhouse workers pause for staging, then the candidate runs as a trial. The new selection becomes recorded good after confirmation. Resident management remains available during a normal service update.
A running application is the start of verification.
After deployment, inspect service health and diagnostics. Then check the behavior you intended: with a fresh, valid reading of 27°C, a fan starting off should now turn on and the display should report it.
Illustrative acceptance check for the proposed policy. Runtime trial confirmation establishes liveness; the fan response and display result establish application behavior.
Take this model into your own application.
Evaluate whether Micros fits your requirements, then follow the architecture or try an existing application.
Contracts behind the story: worker ownership and supervision, bounded channels, composition, and updates and recovery.
- Interactive device shell: inspect services, stream logs and invoke deployed commands.