Status List: file_path is currently required, requiring an additional service/volume mount to serve the list #3084

Current behavior

The status_list plugin requires file_path (or STATUS_LIST_FILE_PATH) to be set at startup. If it is missing, the plugin raises a ConfigError and refuses to load:

This means that even if an organization would prefer a different approach, every deployment must provide a persistent volume and a separate HTTP server to serve the published files.

What we'd like to discuss

The underlying bitstring data already lives in the ACA-Py wallet (Askar) as StatusListShard records. The plugin could expose a public route (something like GET /status-list/{tenant_id}/{list_number}) that assembles and serves the status list on demand with no file system involvement.

This would make file_path optional, allowing:

• Deployments that want static file serving (e.g. for CDN caching) keep the existing publish flow unchanged
• Deployments that prefer simplicity get a working status list endpoint out of the box, with no volume mount or sidecar required

It also opens the door for controllers to handle publishing themselves. A controller would be able to call the publish endpoint after a revocation event and store or forward the result depending on the way their infrastructure is setup, rather than being forced into the file-based path.

Proposed change

1. Add a public GET /status-list/{tenant_id}/{list_number} route that generates the status list JWT on the fly from Askar shard records
2. Make file_path (and the publish-to-file flow) optional rather than required
3. public_uri would point to either the new built-in route or an external server, depending on the deployment

Questions for the community

• Is the file-based requirement intentional for a specific reason we're missing?
• Any concerns with serving directly from ACA-Py (performance, security)?
• Would this be a welcome contribution?

Tagging @timbl-ont. @PatStLouis mentioned your team was using this in production. If we could get your input on this, that'd be great!