Your App Restarts. What Should Remember?

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

Application state is the information your product carries from one interaction to the next: a saved cart, an order, a login session. State management means deciding where that information lives, who can change it, and how long users expect it to last. A deployment replaces the process handling requests. Your storage choices determine what the next process can recover.

Consider a customer who adds two items to a cart, signs in, and places an order while you release a new version. They expect to continue shopping. You need a different answer for each piece of state, because losing a search filter and losing an accepted order have different consequences.

Give each piece of state a lifetime

Keep information in the narrowest place that meets the user's expectation. A component can hold an open menu until the page closes. A browser can retain a guest cart across visits. Store an account's saved cart on the server if the customer expects to find it on another device, and commit accepted orders to durable storage.

Treat login state with the same care. A browser may hold a session cookie while the server keeps the session record. Saving that record in one web process logs the customer out when you replace it. A shared store can preserve the session across application restarts; its expiry and loss policy still need a decision.

Use the session continuity check to test the session store, signing key, cookie scope, and logout across a release.

A stateless process can serve a product with history

Run a stateless web process when the next process can handle a request using the request itself and shared storage. It can still keep temporary calculations in memory. The restriction concerns information that later requests need: another process must be able to obtain it without asking the process that handled the previous request.

In the shop, the replacement process reads the customer's cart and orders from the database. For uploads, keep the file in object storage and its key in the database. A path such as ./uploads/receipt.pdf depends on one container's filesystem; use the upload acceptance check to verify persistence and private access after a release.

Replacement and recovery solve different failures

Store durable records outside the application container so a release can replace code without replacing those records. That separation covers an application restart. Recovery from a deleted table, a damaged disk, or a mistaken update requires another copy and a restore procedure. Keeping data across deployments answers only the first of those problems.

On aidrop.it, application containers have a read-only root filesystem and temporary writable paths. Managed PostgreSQL runs as a separate resource with its own persistent volume. A new application deployment reconnects to that database. The runtime contract makes those storage boundaries visible before an agent chooses where to write.

The application still owns the meaning of a successful request. Confirm an order after its database transaction commits; keep unfinished work identifiable if the process stops. A customer may retry after losing the response, so use a stable request identifier to avoid creating a second order. For data recovery, keep and test a database backup.

A state map for one customer journey

Map a single customer journey before choosing storage for the whole product. Record what a user expects after a browser closes and after an application restarts. The distinction exposes state you can discard, state you can reconstruct, and records for which you need a recovery copy. This example assumes a shop with saved account carts.

STATE MAP: BROWSE -> CART -> ORDER

Open filter panel
  Lives: browser component
  Loss: reset the panel; no customer record lost

Saved account cart
  Lives: database; browser holds a working view
  App restart: reload it for the signed-in customer

Login session
  Lives: browser cookie + shared server-side session store
  Loss policy: decide whether signing in again is acceptable

Accepted order
  Lives: database, with a stable request identifier
  App restart: read the committed order
  Data loss: restore from a tested recovery copy

Receipt file
  Lives: object storage; database holds its key
  App restart: check permission and retrieve by key

FAQ

Does stateless mean an application cannot save data? A stateless web process stores data needed by later requests outside its own memory and local filesystem. Users can still have saved carts, accounts, and order history.

Will a browser store keep state across devices? Browser storage belongs to that browser context. An account's cross-device state needs a server-side record and a way to associate it with the authenticated user.

What survives an application deployment on aidrop.it? On aidrop.it, records in an attached managed PostgreSQL database remain on its separate volume when you replace the application. Process memory and temporary application files do not survive replacement. Customers remain responsible for database backups and restore testing.