Local development & testing

You can develop an app entirely on your machine and only install the manifest when you're ready to test the in-product experience.

Serve your app over HTTPS

Verentis frames apps over HTTPS, so your dev server must serve HTTPS too. Point spec.entry at your dev server while developing:

spec:
  entry: https://localhost:5173

Two ways to run while developing

Libre Office and platform-owned WOPI

Clone verentis/libre-office into a directory named libre-office beside platform (the default clone name). An existing sibling checkout named office remains supported for backward compatibility. Internal workload names intentionally remain office; the package is libre-office. Run npm ci in that checkout, then scripts/setup-certs.sh in platform to set up the shared mkcert wildcard certificate. That setup explicitly changes local CA trust. If the leaf/key are already trusted, use scripts/setup-certs.sh --export-ca-only to export the public root without changing trust.

Start the normal platform AppHost with Collaboration, Node, Security, Resource and Marketplace. Its local Office resources start the Nuxt wrapper and the CODE image pinned by deploy/code.lock.json in the selected checkout. There is no Office WOPI backend. The wrapper normally uses https://office.localtest.me, CODE uses https://office-code.localtest.me, and callbacks go to the platform API gateway's HTTPS origin, not office-wopi.localtest.me.

Use the exact origins and ports reported by your AppHost. Isolated warm-harness slots can use different ports, including the workspace parent origin. CODE must trust the gateway's TLS chain, and the browser must trust the wrapper and CODE certificates.

Apply the local manifest overlay before packing. Sign and publish the package to the local Marketplace, install it in a test workspace, and approve the WOPI document-processing consent. No Office hosted-service registration, client ID or client secret is required, including in the publisher's own workspace. Platform workload credentials and CODE proof material are managed by the local topology. Do not delete their durable local files as a routine restart step.

Open a document from the installed app in the workspace. Direct wrapper navigation lacks the platform embed authorization. An unsigned package created by an offline check is not a live-authorized installation; a standalone API key does not replace this workflow.

The Libre Office repository's docs/live-local-setup.md, README.md and docs/operations.md describe the current wrapper and CODE setup. Run its npm run check and npm run check:framing for component checks; use its npm run test:integration with the platform warm stack for real editing. The platform harness has app-office and app-office-operations scenarios for the core and optional-operation journeys. Mocked CODE messages and wrapper-only checks do not prove end-to-end persistence.

Ordinary app development

A tight loop

1. Edit your app; your dev server hot-reloads.
2. Open (or reopen) a matching file or standalone launch surface in the workspace to reload the iframe.
3. Adjust the manifest to change which files you claim or which permissions you request, then re-detect.

Testing checklist

When you're ready to ship

Host your app at a stable HTTPS URL, set spec.entry (and oauth.redirect-uris if using OAuth) to that URL, bump metadata.version, and prepare to publish.

Next