Changelog

What is new

Generation: images, video and sound from one tool

• One generation tool produces any asset, whatever its format. The tool that used to be called image_generation now also makes video and audio, so the format has left its name. You name a model; the registry resolves the format, the endpoint, the provider, the parameters that model accepts and what it costs. Onboarding a provider adds no new surface to learn. image_generation stays callable as a deprecated alias, because agent tool configurations store names verbatim and dropping the old one would have silently stripped the capability from every agent already configured with it. A new action='models' returns every model id with what it accepts, its limits and its rate, so an agent can weigh the cost before spending anything.

• A generation modal that goes from a format to a finished asset. Three steps in the order the decision is actually made: what to produce, then which model and what to say, then the result. The parameters offered are the chosen model's own, read from the live catalogue rather than hardcoded, and the price is stated with its floor and its ceiling next to the rate, because "4 credits per second" for a model whose minimum is 8 advertises a price no short call can have. It runs through the same path an agent uses, so nothing about validation or pricing is special-cased for the button. A refusal is shown in the provider's own words, since every refusal on this path is something the reader can act on.

• Start a generation from every message composer. Making an image, a video or a sound is often what a message is about, so the entry point now sits in the composer beside the tools that consume one. Direct messages and the builder's chat trigger panels included. The Files page keeps its own button, which moved to the left of "New folder".

• A core:generate node, with the price shown before the run. Generation is a first-class workflow step now, priced per model and per quantity, per image or per second depending on what the model sells.

• Eight more providers, plus OpenAI and Google back on the list. Input assets actually work now, Flux exposes its reference image, and each provider is marked in the dialog. A model that takes files says what each input file is and how many it accepts.

• An agent can be granted generation, with its own toggle. The permission is deliberately separate from the image one rather than inherited from it: that grant was given for images, and a per-second video model spends an order of magnitude more per call, so reusing it would have quietly widened what an already-configured agent may spend.

• A key-based integration now asks whether you want to use your own. Creating a credential opened straight on "paste your API key" whether or not the platform had a key of its own. OAuth2 always had that conversation through the Standard and Custom toggle; key-based integrations never did. For the ones most likely to be resold, which is every generation provider, that quietly made bring-your-own-key the only path ever shown, and the choice it hid is not cosmetic: it decides who pays.

• A fresh install has generation models and prices with no network at all. The catalog dump a new install boots from was last refreshed before generation existed, so an air-gapped or never-linked install had every endpoint with an empty descriptor, a registry that resolved zero models, and no prices to attach to anything. A generated seed now ships inside the image, copied verbatim from the same files that author the catalog, so a descriptor and its price cannot disagree. A shipped price stays replaceable by the first real bundle, while a price an administrator set here is preserved.

• A cloud-linked install can run a seeded generation on the platform key. Every one used to be refused, and the refusal was correct: the relay resolved a price without knowing which model was called or how big the call was, which is two thirds of the question. The cloud now measures the call itself, from the body it already received and with the same descriptor that produced it. Nothing extra travels from the install, and there is nothing for a caller to under-report, which matters because a self-hosted install is the customer's own server: one that declared its own size could call a ten second video one second.

• The legacy image subsystem is gone. Everything goes through the one path, including the interface that displays a generated asset, which had been built against the old shape and was what made deleting the old module unsafe.

Workflow runs

• Run a single node without building a workflow around it. workflow(action='run_node') executes one node immediately from a config, with no persisted workflow and no run, so an agent can check that a configuration works before wiring it in. Nothing is written to the run history; the tool result is the only trace.

• Restart a run from one node instead of firing the whole thing again. An agent whose run went wrong at step 9 of 12 had only "execute", which redid all twelve and paid for them again. workflow(action='restart_from_node') re-runs that node and continues from there, keeping everything the run already produced upstream. On the canvas, "restart from a node" is reachable in automatic mode too, not only step by step.

• The step list is ordered by the graph, not by arrival. A workflow with parallel branches used to list its nodes shuffled, in whatever order the updates arrived, and an epoch that re-fired part of the graph reshuffled them again. The list is now sorted so that a node never appears above anything feeding it, a branch stays contiguous, and each trigger's graph is emitted whole before the next. The Logs table follows the same order.

• Every epoch carries its own outcome. A run accumulates one epoch per trigger fire, and its status could only ever describe the last one, so epoch 2 failing among five green fires was not representable and a failed epoch announced "Completed". Each epoch row is badged from its own recorded state now, named by the same rule the run badge uses, so the two cannot contradict each other.

• "Partial success" describes a node, never a whole run. The verdict is computed in one place on the backend and travels with the run, so the canvas, the panel and the badge cannot each reach their own conclusion from a second copy of the rule.

• Running out of credits fails the run instead of silently not starting it. An out-of-credit workspace was refused before the run even opened, so nothing was persisted and an unattended workflow, a schedule, a webhook, a form, simply looked like it had stopped working, with the only trace in a server log. The check now happens at each node: the trigger node fails with an explicit "credits exhausted" error and the rest of the graph is marked skipped, which is visible in the run. The run stays reusable, so topping up revives the schedule with no further action.

• A run is born with its real trigger. Runs were being created against a placeholder trigger identity that no graph matched, which is the kind of defect that surfaces later as a reset acting on the wrong branch.

• A new epoch no longer inherits the previous one's finished loop. A loop that had terminated stayed terminated for the next fire, so the second run of a workflow could skip its body entirely.

• A rerun after a closed cycle no longer lands in an empty epoch. It resolves its epoch once instead of twice, takes the same per-run lock the trigger and cycle paths already take, so a concurrent fire cannot move the epoch under the decision, and the wave cap that stops a runaway now says that is what it is.

• The derived status of a run counts every node. Core, agent and table nodes were left out of the calculation, so a run could report an outcome that its own steps contradicted.

Step-by-step runs

• A refused step says which of four situations it is in. "Cannot run this node" covered a node already running, a node in another epoch, a node in a different graph and a genuine server error, which need four different reactions from the reader. Each is now named, the live state is read from the shared cache rather than re-derived, the classification is done against the current epoch, and a server error is no longer reported as a refusal. Advice to re-run a node that is running right now is gone.

Integrations

• 181 new integrations, and the catalog now says 700+. Three lots: 98 chosen by comparing the catalog against the full n8n integration inventory, 38 more closing the remainder of that gap, and 45 widely-used platforms picked from npm download weight and by category. Every one ships with its own icon. Integrations that could not be made to work honestly were documented and left out rather than shipped broken.

• Request bodies on GET and DELETE were being dropped. A whole class of endpoints declared body parameters that never reached the provider, so the call went out incomplete and the failure looked like the provider's. Fixed at the engine and in every endpoint that matched, with a check in the build so the shape cannot come back.

• Eleven asynchronous endpoints returned an empty object on success. They now describe what they actually hand back.

• An integration that declares no authentication prefix gets none. "Bearer" was being forced onto keys that must travel bare.

• A refusal from an integration reads as a sentence. The raw machine envelope was being handed to the reader.

• WhatsApp integrations describe what they really return. The Evolution API and WAHA endpoints had output shapes that were partly invented: group creation, participant updates, contact and chat lookups, instance lists, number checks, QR codes and screenshots are all corrected against live responses, and endpoints that could not work were removed rather than left in the list.

Files

• The folder you are in lives in the URL. A refresh, a Back, or a shared link lands on the same folder, and the breadcrumb is rebuilt from scratch when you arrive cold. Your view and sort choice are remembered.

• Clicking the same folder twice no longer stacks the breadcrumb. A slow listing keeps the previous folder's cards on screen, and every extra click pushed another crumb, so the header could read "Run 12 / Run 12 / Run 12" and took three Backs to leave. A click that is being ignored now dims the stale cards, so it is visible rather than mysterious.

• A file produced by an integration is filed under the run that produced it, instead of landing loose.

• The type filter is a select beside Category, rather than a separate row of controls.

Marketplace and applications

• The marketplace ranks by popularity instead of by date. It was a chronological feed, so a popular application sank as soon as anything else was published. Browsing now orders by a score built from measured signals only: favourites, installs, and rating weighted by how many reviews back it, so a lone five-star cannot outrank a 4.5 with twenty behind it. Publications with no engagement keep their previous order rather than moving somewhere arbitrary. The default sort is by rating, and the explore filters have been extended.

• Reviews show who wrote them. Every review was rendered as "Anonymous", because the name was read on one end and injected by nobody on the other. Highlights carry the rating and the install count too.

• An application can load its example values and reset its data. Two actions in the application toolbar, so they reach the page, the side panel and fullscreen from one place. Loading the examples seeds the interface forms and the trigger panel without submitting anything. Publishers can see the example values they are shipping.

• The Application tab opens on the epoch you picked in the Run tab, instead of resetting to the newest one.

Your account

• Deleting an account is cancellable, from inside the app. The backend already refused to purge anyone who signed back in, so nobody was being destroyed by mistake, but that left them stranded: the account stayed blocked, and nothing in the app offered a way back. Signing in now opens a dialog that names the date the purge will act on, explains that nothing has been deleted yet, and offers to reactivate or sign out, translated in all six languages. The deletion itself now removes everything it claims to, the deferral is bounded, and the interstitial no longer defers the deletion it just triggered.

Builder and interfaces

• Opening a workflow is no longer an undoable edit. The first Undo after loading a workflow undid the loading.

• File previews stay open when you pan the canvas, and whether they are open is a remembered preference rather than a one-shot action on whatever is currently on screen. The control stays available in edit mode and on runs that produced no file, which is exactly when you would want to ask for it.

• A navigate action in an interface is matched by its event, not by guessing from a prefix.

• An agent-facing description now names where a file object comes from, on both ends of the join, and the mocking rules state that a mocked file reference needs its id.

Look and feel

• One radius ladder across the app. The accent button in the corner of the agent fleet canvas and the one on the workflow canvas are the same object in the same place, and they were drawn as a 44px circle and a 36px square. They share one shape now, and so does everything else that had stayed a capsule: node icons became square-rounded tiles, the step buttons in modals, the send button in the composer, the Install and Open buttons in highlights, and the loading placeholders in Settings, which now have the shape of what they are standing in for. A collapsed sidebar icon looks like the row it stands for.

• Every multi-step dialog has the same header, including the green completed step.

• Page actions no longer push list pages sideways on a phone.

Under the hood

• Tool results keep their metadata on OpenAI-style CLI backends. One missing unwrap was dropping every tool result's trusted metadata on those paths, which is what draws the Connect and approval cards, so they never appeared.

• The gateway strips the headers that decide what a call costs, so a client cannot describe its own bill. An unreadable success response is an error again rather than a silent acknowledgement, on both the tool path and signal resolution.

• A pinned credential may only reach its own provider, and never leaves in a shared plan.

• Two more browser-agent models route correctly. Qwen and Moonshot go through the OpenAI-compatible mapping.

• Cloud-linked installs are told what the cloud switch covers, and when it cannot pay.

• A public export no longer carries the production network range, and the Keycloak guards fire for the lane that actually edits production.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.12

• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.12

• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.12

• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.12 (opt-in renderer profile)

• docker.io/livecontext/livecontext-ce:v0.2.12

• docker.io/livecontext/livecontext-ce-frontend:v0.2.12

• docker.io/livecontext/livecontext-ce-bridge:v0.2.12

• docker.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.12 (opt-in renderer profile)

• quay.io/livecontext/livecontext-ce:v0.2.12

• quay.io/livecontext/livecontext-ce-frontend:v0.2.12

• quay.io/livecontext/livecontext-ce-bridge:v0.2.12

• quay.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.12 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

What is new

Upgrading

• A self-hosted install upgrades cleanly again. Two migrations that only ever applied to the hosted edition were not neutralised for CE, so an existing install could refuse to boot after pulling a newer image. They are skipped now, as the rest of the cloud-only schema already was.

Workflow canvas

• Every button attached to a node is square now. The buttons hanging off a node were the last round islands left on the canvas: pills that grew under the pointer and carried a drop shadow, sitting next to flat square chrome. The bottom bar, the play and rerun buttons, the trigger pin and its launcher, the fleet triggers, delete and duplicate, and the "+" that adds a node from a handle all take the same shape as the rest of the app. One shared style rather than four copies of it, which is what had let the pin button quietly lose its outline.

• A run can be launched again from an epoch you are reading. Opening one epoch of a run is a record, so the controls under a node step aside. That left no way to fire the workflow again without going back to the cumulative view first, and for a chat, form or webhook trigger no way at all. Every trigger now offers its run button while an epoch is focused: it returns to all epochs, then does exactly what that trigger normally does, fire immediately or open the panel where you type the message or fill the form. The button stands down on the run's newest epoch, where the normal one is already there, and stays away on a finished run, which cannot be fired into.

• Step-by-step runs can be stepped from the canvas again. Since the run history moved into the side panel every run surface opens through an epoch, and the play and rerun buttons on non-trigger nodes silently vanished with it: no error, badges still drawn, and a run that simply could not be advanced. Reading the live state through its own epoch is not history, so it stays a console; only an older epoch is read-only.

• See what a run produced without opening every file. A run with a dozen file-producing nodes meant clicking each preview one by one. The canvas toolbar carries a single control that unfolds them all, or folds them back, and it only appears when the canvas actually shows a file.

Run panel

• The run bar counts the epochs a run has. It was reading the engine's internal cursor, which moves on to the next epoch as soon as one finishes, so a workflow fired once announced "All epochs (2)" directly above a list showing one. The number and the list now come from the same place.

• The sub-workflow tab has its run history back. The tab opened on one run, the pinned production one, and stopped there: no way back, no way to reach another run of that workflow. Picking a run there now lands, and does it without dragging the page behind the panel along with it. Coming back up to the list, the run you were reading is marked, so "which one was that?" has an answer.

• Reviewing an approval shows the item you are deciding on. Clicking a pending item opened the review with the variable picker where the item's own data belongs, so the decision was made blind. A node under review now counts as having run data to inspect, and the reviewer sees the input that item arrived with.

Execution

• A step that reads a value which does not exist now fails, instead of running on emptiness. A parameter pointing at an output no node ever produces used to resolve to nothing and let the step proceed, so the failure surfaced several nodes later as an unrelated error, or not at all. It stops at the step that asked for it, and says what it was looking for.

• The output names an agent is given are the ones actually written. The builder handed agents keys no mapper ever produces, so a workflow could be wired to a field that never exists at runtime. The documented outputs are aligned with what each node really writes, the Switch node's selected branches included, which had been described as a list while it has always been a string.

• Data tables read and write in the workspace you are actually in. The table views sent no active-workspace header, so an account belonging to several workspaces could be shown the wrong one's rows.

Sub-workflows

• A sub-workflow that cannot run says what to do about it. The "no active run" message had lost the sentence naming the action that creates one, leaving a dead end where there was a next step.

Under the hood

• A lighter image and a tidier tree. Unreachable frontend files, dead backend code, an unused 19 MB landing animation and 29 MB of stray build artefacts are gone; two unused dependencies and a duplicate lockfile with them.

• Every interface string exists in every language. Locale parity is now guarded repo-wide rather than trusted, so a key added in English can no longer ship untranslated to the other five.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.11

• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.11

• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.11

• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.11 (opt-in renderer profile)

• docker.io/livecontext/livecontext-ce:v0.2.11

• docker.io/livecontext/livecontext-ce-frontend:v0.2.11

• docker.io/livecontext/livecontext-ce-bridge:v0.2.11

• docker.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.11 (opt-in renderer profile)

• quay.io/livecontext/livecontext-ce:v0.2.11

• quay.io/livecontext/livecontext-ce-frontend:v0.2.11

• quay.io/livecontext/livecontext-ce-bridge:v0.2.11

• quay.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.11 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

What is new

What is new

Workflow runs

• The run you pick is the run you keep. Picking a run in the run history bound the canvas to it but left the address bar on the run the page had been opened with. A refresh therefore took you back to the previous run, and the run you were reading could be neither shared nor bookmarked. The address bar now follows your pick, still without reloading the page, and the browser's Back button behaves: coming from the editor returns to the editor, switching between runs does not fill your history with them.

• A run opens on all of its epochs. Opening a run landed on its most recent epoch, hiding every other fire behind a selector nobody had touched. The cumulative view is the default again on the canvas, in the Run panel and in the workflow page's Application tab, and both the run bar and the application's epoch control say "All epochs" in words instead of a number that read like an epoch. Picking one epoch still sticks across surfaces, and so does going back to all of them. A published application, where the app itself is what you came for, still opens on its newest run.

• The run history shows the real execution time. The duration column measured an epoch's whole lifetime, idle tail included, so a workflow whose executions take seconds reported hours (32h42m for a run of a few seconds). It now measures from the first node start to the last node end, and a wait inside the graph still counts because the waiting node's own row spans it. The same wrong figure was reaching the epoch timeline, the Application tab, the agent fire result and macro report, and the public app and showcase payloads; all of them now read the corrected value.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.10

• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.10

• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.10

• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.10 (opt-in renderer profile)

• docker.io/livecontext/livecontext-ce:v0.2.10

• docker.io/livecontext/livecontext-ce-frontend:v0.2.10

• docker.io/livecontext/livecontext-ce-bridge:v0.2.10

• docker.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.10 (opt-in renderer profile)

• quay.io/livecontext/livecontext-ce:v0.2.10

• quay.io/livecontext/livecontext-ce-frontend:v0.2.10

• quay.io/livecontext/livecontext-ce-bridge:v0.2.10

• quay.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.10 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

What is new

Workflow builder

• The node palette is usable in the bottom dock. Opening Add Node with the panel docked at the bottom showed "Frequently Used" and nothing else, with no scrollbar to reach the rest. The palette is one scrolling list now, with the search and the breadcrumb pinned above it. Drilling into a category also lands at the top of the list instead of part-way down, and the Frequently Used grid lines up with the rest of the panel.

• The run bar opens the run panel. Clicking the bar (or pressing Enter or Space on it) opens the current run. The version chip still opens the run history, and stop or cancel still stops the run.

• Stop is always reachable. Stop, cancel and reactivate move to the far right of the run bar, on the canvas and in the side panel alike, and sit outside the scrolling area so they can never scroll out of reach.

• The run chips scroll instead of vanishing. On a narrow canvas or inside a side panel the chips were hidden below certain widths, which also hid the only route into the run history. They scroll horizontally now.

Look and feel

• The mode toggle, the run bar and the bottom canvas toolbar now use the same flat square controls as the rest of the app, at one shared height, and follow the light and dark palettes instead of hardcoded colors.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.9

• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.9

• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.9

• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.9 (opt-in renderer profile)

• docker.io/livecontext/livecontext-ce:v0.2.9

• docker.io/livecontext/livecontext-ce-frontend:v0.2.9

• docker.io/livecontext/livecontext-ce-bridge:v0.2.9

• docker.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.9 (opt-in renderer profile)

• quay.io/livecontext/livecontext-ce:v0.2.9

• quay.io/livecontext/livecontext-ce-frontend:v0.2.9

• quay.io/livecontext/livecontext-ce-bridge:v0.2.9

• quay.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.9 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

What is new

Workflow builder

• The node palette and the run history now live in the side panel. The canvas keeps the space; both are one click away instead of covering what you are editing.
• Run-mode trigger picker, pinnable from the canvas toolbar. Choose which trigger a manual run fires without leaving the canvas, and pin the one you keep using.
• Loop-back edges, n8n style. An edge can now point back at an earlier node without a dedicated While hub, so iteration reads the way you draw it.
• Sub-workflow nodes no longer show the referenced workflow's name, which went stale as soon as the target was renamed.

Agents

• An agent can stop a run - including the one it is executing inside, which previously had no way to end itself.

Marketplace

• CE-exclusive publications, badged as such and blocked on managed cloud.

Fixes

• The execution engine no longer resets an epoch while an async agent is mid-delivery, which could drop that agent's result.
• Chained workflow triggers fire again; the same lazy-proxy dispatch bug that broke them also affected the sub-workflow and error-trigger lanes, now resolved through one path.
• Loop iteration caps are enforced consistently across replicas.
• interface-client's default HTTP client had no read timeout at all: a single unresponsive interface call could hang a worker indefinitely. It is now bounded.
• The workflow builder stops accepting parameter aliases that no creator ever read, so a typo fails loudly instead of being silently ignored.

Self-hosted release notifications

Your install learns about a new release from a public feed on the cloud. That feed used to be updated by hand as part of a cloud deployment, and it silently fell behind for months - installs were told they were current when they were not. It is now written by the release itself, after its smoke-test passes, so a published release and an announced release cannot diverge.

Nothing changes in how you update: the in-app banner links to the release notes, and updating is still docker compose pull then up -d.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.8

• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.8

• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.8

• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.8 (opt-in renderer profile)

• docker.io/livecontext/livecontext-ce:v0.2.8

• docker.io/livecontext/livecontext-ce-frontend:v0.2.8

• docker.io/livecontext/livecontext-ce-bridge:v0.2.8

• docker.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.8 (opt-in renderer profile)

• quay.io/livecontext/livecontext-ce:v0.2.8

• quay.io/livecontext/livecontext-ce-frontend:v0.2.8

• quay.io/livecontext/livecontext-ce-bridge:v0.2.8

• quay.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.8 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.7

• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.7

• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.7

• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.7 (opt-in renderer profile)

• docker.io/livecontext/livecontext-ce:v0.2.7

• docker.io/livecontext/livecontext-ce-frontend:v0.2.7

• docker.io/livecontext/livecontext-ce-bridge:v0.2.7

• docker.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.7 (opt-in renderer profile)

• quay.io/livecontext/livecontext-ce:v0.2.7

• quay.io/livecontext/livecontext-ce-frontend:v0.2.7

• quay.io/livecontext/livecontext-ce-bridge:v0.2.7

• quay.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.7 (opt-in renderer profile)

• registry.gitlab.com/livecontext/livecontext/livecontext-ce:v0.2.7

• registry.gitlab.com/livecontext/livecontext/livecontext-ce-frontend:v0.2.7

• registry.gitlab.com/livecontext/livecontext/livecontext-ce-bridge:v0.2.7

• registry.gitlab.com/livecontext/livecontext/livecontext-ce-screenshot-renderer:v0.2.7 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.6

• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.6

• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.6

• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.6 (opt-in renderer profile)

• docker.io/livecontext/livecontext-ce:v0.2.6

• docker.io/livecontext/livecontext-ce-frontend:v0.2.6

• docker.io/livecontext/livecontext-ce-bridge:v0.2.6

• docker.io/livecontext/livecontext-ce-screenshot-renderer:v0.2.6 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.5
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.5
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.5
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.5 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

Pull from whichever registry you prefer, the digests are identical.

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.4
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.4
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.4
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.4 (opt-in renderer profile)

Each image is also tagged v0.2, v0 and latest if you prefer to track a moving line rather than pin an exact release.

What is new

Launch with one npm command.

You can now start LiveContext CE with a single command, next to the existing Docker Compose flow:

npx livecontext

It checks Docker, pulls the images, fetches the current model catalog, boots the whole stack and serves it on http://localhost:3000. Docker stays the runtime; the CLI just orchestrates it. Subcommands: up (default), down, logs, status, update.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.3
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.3
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.3
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.3 (opt-in renderer profile)

What is new

Never-linked installs now ship with the release-day model refresh.

The monolith image now bakes the cloud's active signed model bundle (catalog-seeds/model-bundle.json) so a fresh, never-cloud-linked install applies the latest curated models at first boot instead of only the build-time classpath baseline. Cloud-linked installs are unchanged (they already sync the latest bundles).

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.2
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.2
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.2
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.2 (opt-in renderer profile)

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.1
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.1
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.1
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.1 (opt-in renderer profile)

What is new

LiveContext CE is now open source (AGPL-3.0)

LiveContext Community Edition is now licensed under the GNU Affero General Public License v3.0 (AGPL-3.0), an OSI-approved open-source license, replacing the previous source-available license.

What this means for you

• Use it commercially, self-host it, modify it and redistribute it, freely.
• If you run a modified version as a network service, AGPL asks you to make the source of your changes available to that service's users.
• The LiveContext name and logo remain trademarks (see TRADEMARKS). The license covers the code, not the brand.
• Older releases keep their original license. This change applies from v0.2.0 onward.

Also in this release

• Refreshed the README product screenshots with real captures: Workflow + App (the workflow and the app it drives, in one view), Agents, Tables and Data & metrics.
• Added THIRD_PARTY_NOTICES and a draft TRADEMARKS policy; updated NOTICE and CONTRIBUTING. The DCO sign-off flow is unchanged.

Contributing

Contributions are welcome under AGPL-3.0 with a DCO sign-off (git commit -s). See CONTRIBUTING.md. Questions or ideas? Open a Discussion.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.2.0
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.2.0
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.2.0
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.2.0 (opt-in renderer profile)

What is new

Highlights

Approvals

• Customizable Telegram approve/reject button labels per approval node (delegation.approveLabel / rejectLabel, template-capable). Without labels the classic Approve / Reject buttons are unchanged.
• Optional image on Telegram delegation: photo, caption and buttons in a single message.
• New continuationMode per_item for approvals inside a Split: each approved item continues immediately instead of waiting for every sibling.

Email automation

• Email Inbox (IMAP) and Send Email (SMTP) nodes: correct builder credential detection. No more false credential

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.22
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.22
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.22
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.22 (opt-in renderer profile)

What is new

Highlights

Side panel & AI Chat

• Dock the side panel where you want it. The header now has two dock buttons: open the panel on the right or at the bottom. A per-workspace preference chooses the default opening position (right or bottom), so the panel opens where you like across the whole app; the two buttons still override it on the fly.
• Full-width bottom dock. A "full width" bottom style spans the whole window (sidebar shrinks above it), ideal for demos and screen recording. A "content width" style keeps it beside the sidebar. Both are a preference in Settings.
• Centered AI Chat welcome. Opening the side-panel AI Chat on an empty conversation now shows a centered composer with a "How can I help you?" title, matching the main chat and the workflow panel.

Interface & search

• Refreshed UI. A cleaner, ElevenLabs-inspired design pass across buttons, form controls, and modals, plus inspector-toolbar and sidebar polish.
• Global search. A search bar in the header to jump across your workspace quickly.

MCP server

• Multiple scoped API keys. Create several named lc_live_ keys, each limited to specific tools (per-tool scopes), so you can hand out least-privilege access to external MCP clients.

Integrations

• Connect Reddit with a one-click OAuth2 flow (authorization code + refresh).
• TikTok: video upload tooling with provider-signed (dynamic-URL) upload/download endpoints, plus OAuth token-flow fixes (correct client-id parameter, comma-delimited scopes, BYOK-only publish/research scopes).
• OAuth: data-driven support for non-standard token flows and a configurable client-id request parameter, broadening the set of providers that connect cleanly.

Fixes

• The agent chat widget is now removed when you turn it off while editing an agent (it previously stayed live).
• Catalog credential-invalidation calls are signed, so flipping an integration's auth type and re-importing no longer fails with a 401.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.21
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.21
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.21
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.21 (opt-in renderer profile)

What is new

What's new in v0.1.20

Features

• Side panel dock position (Right or Bottom). A new preference in Settings > Preferences lets you dock the unified side panel under the content (full width, opens top to bottom, resizes by height) instead of only to the right. The choice is remembered per workspace and the header toggle icon mirrors it (right vs bottom).
• Workflow AI Chat panel: centered welcome composer. The empty AI Chat tab now shows a centered "How can I help you?" composer, and the canvas hero is hidden while the panel is open.

Fixes

• Chat: correct agent avatar in the composer. The composer now resolves the linked agent from the conversation's forward link, so it shows the right agent avatar instead of falling back to the model selector.
• Chat: workflow-assistant inherits your chat defaults. Workflow-assistant conversations now seed from your Preferences chat defaults (temperature, web search, and the rest).
• Catalog: DeepSeek V4 empty responses fixed. Corrected stale output-token caps that were causing empty agent responses.
• Workflow in-place runs. An agent-launched run now overlays on the canvas in place (no page refresh), shows the Trigger/Application sub-tabs, and loads the Application with a pulse (not a spinner) for running steps.
• Pricing: shortened the CE platform-credentials label.

Internal

• Reverted a late-subscriber snapshot re-request; added an e2e test covering workflow-conversation chat-defaults inheritance.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.20
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.20
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.20
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.20 (opt-in renderer profile)

What is new

What's new in v0.1.19

Consistent text filter on every list action

All agent-tool list actions now accept the same query free-text filter, so listing workflows, tools, runs, and the rest narrows results the same way everywhere instead of each action having its own (or no) filter. Covered by a live CE MCP contract test.

Live updates: no more missing snapshot for late joiners

Fixed a websocket race where a handler that subscribed to an already-open channel could miss the initial state. A late-joining handler now re-requests a snapshot, so panels that mount after a stream is live still render the current data.

Workflow canvas follows the agent

When the agent runs the workflow you have open, the left canvas now flips to run mode automatically, so you watch the execution live instead of staying on the edit view.

Security and polish

• Removed 4 over-broad Google scopes from the shared verified OAuth client, tightening what the platform requests by default.
• Footer social icons are left-aligned with tighter, more consistent responsive spacing.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.19
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.19
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.19
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.19 (opt-in renderer profile)

What is new

What's new in v0.1.18

Public blog and careers

A public marketing blog is now live at /blog, with localized versions for English, French, German, Spanish, Portuguese, and Chinese. Seven launch articles cover niche-data and AI-automation topics (no-code, workflow vs agent, agent cost budgets, audit trail), each with author bylines and cover images. Full SEO wiring: per-locale canonical and hreflang, BlogPosting and Blog JSON-LD, OpenGraph cards, and server-rendered content for crawlers. A footer Blog link, a header Blog nav entry, and a Careers "Soon" badge round it out.

Marketplace install progress on the card

Confirming an install now returns you straight to the marketplace, where the publication card itself shows the progress: the interface preview un-greys from left to right as the gauge fills to 100%. Once installed, an Open button replaces Install and deep-links into the app. The install state now lives in a shared store, so an install you start from a preview page keeps progressing on its card after you navigate back.

Review approvals from the board and the inbox

Pending User Approval steps can now be reviewed without leaving the page. Board cards that need review get a "Review approvals" button, and the header inbox surfaces Open and Review actions on approval rows, both opening the same review dialog. Also fixed: the split-approval review no longer closes on the last remaining item, and pinning a tested run to production now correctly emits that run's approval and failure notifications.

CE: edit a downloaded application's workflow

Self-hosted installs that acquire an application from the community marketplace now also receive the decoupled, editable workflow twin, matching the local and cloud acquire paths. Previously a cloud-linked CE install got only the run-only application clone and could not edit the downloaded workflow.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.18
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.18
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.18
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.18 (opt-in renderer profile)

What is new

What's new in v0.1.17

Approval delegation to Telegram: now works out of the box

• The Telegram bot credential is now OPTIONAL on the User Approval node's Delegate

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.17
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.17
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.17
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.17 (opt-in renderer profile)

What is new

Highlights

• Approve workflows from Telegram: User Approval nodes can now delegate the decision to Telegram. The approval request arrives as a Telegram message with inline Approve / Reject buttons, and tapping one resolves the workflow approval, including from your phone.

Fixes and improvements

• Server-side rendering of the public pages restored: pages previously shipped an empty HTML shell and rendered entirely in the browser. First paint is faster and content is correct for crawlers, link previews and no-JavaScript clients.
• React hydration errors eliminated on public pages: fixed multi-child <style> tags rendering empty on the server, styled-jsx components without an SSR registry, and locale-dependent number formatting in the pricing section.
• Guard against CDN caching of React Server Component payloads: behind proxies or CDNs that ignore the Vary header (Cloudflare among them), a cached RSC navigation response could be served as the page document. Flight and prefetch responses now always carry Cache-Control: private, no-store. Relevant to self-hosted deployments behind a caching proxy.
• Docs: the sidebar active state and previous / next links now render correctly server-side on the documentation pages.
• New public comparison pages on the cloud site (livecontext.ai/compare) and an llms.txt for AI crawlers.

Database migrations

This release includes two schema migrations (V393 approval channel deliveries, V394 approval delegation node docs). They are applied automatically on startup by the migration service; no manual action is needed. As always, update with docker compose pull && docker compose up -d.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.16
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.16
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.16
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.16 (opt-in renderer profile)

What is new

Changed

• Landing and social preview image. Shared links to a LiveContext instance now render a proper 1200x630 product card (a live run dashboard) instead of a small square logo, on X, LinkedIn, Slack and other platforms. og:image and twitter:image now match the summary_large_image card type.

Docs

• README. Added dynamic project badges (GitHub stars, latest release, discussions), a star call to action, and a one line summary: an open-source, self-hosted alternative to n8n, Zapier and Make, with AI agents built in.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.15
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.15
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.15
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.15 (opt-in renderer profile)

What is new

Added

• Empty model pickers now tell you how to get models. On an install with no cloud link and no provider API key, every model picker (chat composer, agent create/edit modal, workflow node inspectors for Agent/Classify/Guardrail/Browser Agent) used to render silently empty. They now show a clear call to action: Connect to LiveContext Cloud (recommended, one click - the flow completes on Settings > Cloud account) or Add an API key (jumps to Settings > AI Providers). Non-admin members see a note to ask their administrator instead of buttons they could not use.

Fixed

• Pickers refresh immediately after connecting or adding a key. The cached model catalog is now dropped when the install links/unlinks LiveContext Cloud and when a provider API key is saved or removed, so the pickers repopulate right away instead of staying empty for up to five minutes.

Updating

git pull then docker compose pull && docker compose up -d.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.14
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.14
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.14
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.14 (opt-in renderer profile)

What is new

Added

• Optional components now tell you when they are missing. When an install runs without the opt-in docker profiles (screenshot/PDF renderer, browser agent), the related features used to fail silently. The workflow builder now warns on the affected nodes, a Settings card lists each optional component with its enable command, and AI agents are told which components are unavailable so they stop suggesting them.

Fixed

• Model execution links are honored everywhere. The browser agent could previously bypass an admin's execution link and run on the original provider key; it now resolves the linked target like every other surface, while billing stays on the billed model. Also fixed: deleting a link whose model id contains a slash (e.g. OpenRouter ids), a case where an upsert with a string "true" silently persisted a disabled link, and cache consistency under concurrent updates.

Recently in this release train

• v0.1.12: a brand-new install now lands on administrator-account creation ("Set up your LiveContext") instead of the "Welcome back" sign-in dead end.
• v0.1.11: fresh installs start with the current AI model catalog (signed bundle applied at first boot, no cloud link needed) and the billing 404 console noise is gone. Updating from v0.1.10 or earlier picks up all of the above with git pull + docker compose pull + docker compose up -d.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.13
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.13
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.13
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.13 (opt-in renderer profile)

What is new

Fixed

• A brand-new install now starts with account creation, not a login wall. The very first visit used to land on "Welcome back. Sign in to continue where you left off.", a dead end when no account exists yet. A fresh install now routes straight to "Set up your LiveContext", the creation of the administrator account (your intended destination is preserved and used right after signup). As soon as any account exists, the normal sign-in page is back. Installs that already have accounts are unaffected.

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.12
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.12
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.12
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.12 (opt-in renderer profile)

What is new

Fixed

• Fresh installs now start with the current AI model catalog. Each release bakes the cloud's signed model bundle into catalog-seeds/model-bundle.json, and the app verifies and applies it at first boot, no cloud link needed. Previous releases (v0.1.9/v0.1.10) shipped without that file due to an export bug, so new installs only saw an outdated built-in model list. Existing installs pick it up with git pull + docker compose up -d (the bundle is applied at the next start; your own model edits are preserved). Continuous updates between releases remain a benefit of linking the install to LiveContext Cloud.
• Removed the billing 404 noise on every page. Community Edition no longer calls the cloud-only PAYG billing endpoint, which fired a failed request and an "Error fetching PAYG tiers" console error on every page navigation right after first login.
• Cloud AI relay reliability (linked installs). Relayed model calls now always execute on the real provider API; a platform-side execution-link configuration can no longer break relayed models with an opaque 400 error.

Internal

• The release pipeline now fails loudly if a release would ship without its model refresh (pre-tag publish test, post-publish verification, and a boot-time apply assertion in the release smoke test).

Update an existing install

git pull
docker compose pull
docker compose up -d

The compose file pins this release's image tag, so run git pull first. Your data lives in Docker volumes and is kept across updates.

Fresh install

git clone https://github.com/livecontext-ai/livecontext-ce
cd livecontext-ce
docker compose up -d

Then open http://localhost:3000

Images

• ghcr.io/livecontext-ai/livecontext-ce:v0.1.11
• ghcr.io/livecontext-ai/livecontext-ce-frontend:v0.1.11
• ghcr.io/livecontext-ai/livecontext-ce-bridge:v0.1.11
• ghcr.io/livecontext-ai/livecontext-ce-screenshot-renderer:v0.1.11 (opt-in renderer profile)