Appwrite's Presences API and Git deployment triggers: ephemeral state and build control as first-class primitives

Appwrite shipped a batch of updates this week, and two of them are worth more than a headline scan because they tackle problems that look trivial until you run them at scale. The Presences API addresses ephemeral state, the kind of data that is worthless five seconds after it is written. Git deployment triggers address build amplification, where a one-line change kicks off ten unrelated rebuilds. Both are old distributed systems problems wearing new product names.

The problem with presence

Presence sounds simple. Show a green dot when a user is online, show "typing..." when someone is composing a message, list who is currently viewing a document. Every collaborative app needs it. Almost every team builds it badly the first time.

The trouble is that presence is short-lived state with no natural owner of its lifecycle. A user opens a tab and goes online. Then their laptop sleeps, their wifi drops, or they force-quit the browser. No clean disconnect event arrives. If you stored "online" as a normal database row, that row now lies forever. You end up with thousands of ghost users who appear active because nothing told your system they left.

The naive fix is a heartbeat. The client pings every few seconds, and a background job sweeps the table deleting any record whose last ping is stale. This works, but now you own a write-heavy hot path (every client writing every few seconds), a cleanup job that must run reliably, and a tuning problem where too-aggressive expiry flickers users offline and too-lax expiry keeps ghosts around. You have also coupled a high-churn workload to your primary datastore, which is usually optimized for durable data, not data that dies in ten seconds.

What Appwrite is offering

The Presences API treats this as a distinct class of state rather than forcing it into the normal document model. The two design choices that matter are automatic expiry and built-in Realtime channels.

Automatic expiry means presence records carry a time-to-live and vanish on their own. This is the right model. Ephemeral state should be expiring state by default, so a dropped connection self-heals instead of requiring an explicit teardown that may never come. It is the same logic behind DNS TTLs and session tokens: assume the writer might disappear, and make the absence of refresh the signal for removal.

Built-in Realtime channels mean that when presence changes, subscribers hear about it through the same subscription mechanism Appwrite already uses for database and storage events. You are not polling for who is online. You subscribe, and changes push to you. Permission-aware subscriptions extend Appwrite's existing access rules to these channels, so a client only receives presence for resources it can actually see. That last part is easy to forget and expensive to retrofit. A presence system that broadcasts to everyone is a data leak waiting to happen.

The trade-off worth naming: presence is, by construction, eventually consistent and lossy. A user who just closed their tab may still show as online until the TTL lapses. That is fine for a green dot and unacceptable for anything you would gate access on. Use presence for hints, not for authorization or correctness-critical decisions. The API's design leans into this, and you should too.

Appwrite paired the launch with a Snapchat-clone tutorial built on TanStack Start, TablesDB, Functions, and Storage, walking through live activity, disappearing content, and presence-driven interactions. Disappearing content is a fitting demo, since it is the same expiry-by-default idea applied to messages instead of status.

Git deployment triggers and the monorepo build problem

The second feature is less glamorous and arguably more useful day to day. Git deployment triggers let you control which branches and which file changes actually produce a deployment for Appwrite Functions and Sites.

The problem here is build amplification in shared repositories. In a monorepo, a single push touches one service, but a dumb CI configuration rebuilds and redeploys everything. Edit the documentation, and three backend functions redeploy for no reason. This wastes build minutes, but the real cost is risk. Every unnecessary deployment is a chance to ship a regression, invalidate a cache, or restart a healthy process. Deployments should be a function of relevant change, not of any change.

Branch and path filtering fixes this by making the deployment a conditional reaction. Production deploys only from the production branch. A function redeploys only when files under its directory change. Preview environments spin up for feature branches and nowhere else. This is the same principle as cache invalidation: invalidate precisely what changed, not the whole store, because over-invalidation is just a slower way of having no cache at all. Teams running staging, previews, and production from one repository get the cleanest benefit, since the filters let each environment listen for exactly the changes it cares about.

Runtime and AI updates

The rest of the roundup is shorter. Appwrite added Dart 3.12 as a Functions runtime and Flutter 3.44 as a build runtime for Sites, which lets Dart and Flutter developers keep one language across client, serverless backend, and deployment. They also covered Claude Opus 4.8, breaking down fast mode, effort control, pricing, and what dynamic workflows mean for building agentic systems.

The pattern underneath

Strip the branding off both headline features and you find the same lesson. Presence works when expiry is the default and absence is treated as a signal. Deployments work when they react to relevant change instead of all change. In both cases the win comes from refusing to treat transient or partial events as if they were durable, global facts. That is the distinction that separates systems that degrade gracefully from systems that accumulate ghosts and rebuild themselves to death. The full set of posts is on the Appwrite blog.