Lyre / documentation
Get Lyre

Run your app’s services remotely

Start a project’s scripts on the host, reach them from another screen, and expose one on a URL when you need to.

On this page

1 · Start a service on the host

Lyre starts the commands you configure, on the computer running the host. They are declared as scripts in the project’s lyre.json or its supported legacy name paseo.json.

  1. Open the Scripts section

    From the workspace menu choose Show setup (in Guided mode that menu is called More), then open the Scripts section.

  2. Add a preview service

    Choose Add script, name it preview, enter the command that starts your frontend, and turn on Run as a service.

  3. Add a backend on a different port

    If your app has a separate backend, add a service named backend, api or server. Lyre starts one named companion before the frontend you chose.

  4. Save and start

    Save the project’s settings, then start the app from the workspace’s app/service control.

Ports

New services receive a port through PASEO_PORT; make your command read it, or set a matching fixed port. See connecting an existing app and start commands by app type for worked examples.

It worked when

the service appears in the workspace with a port and starts without a port conflict.

2 · Reach it from another device

The app runs on your computer; the device connects to it. Start with both on the same trusted network, pair the device, and open the approved app.

What you want What it needs
App preview on your own network Free.
Live app preview from outside your network A supported remote connection; included on Free within the application relay allowance. See plan limits.
Remote development (connecting, editing, agents, starting projects) Free.
  1. Keep the host ready

    Leave the computer awake with Lyre running. If it is unreachable, the device cannot start the app.

  2. Open the app on the device

    Use Apps on the paired device. See connectivity and testing from another screen.

It worked when

the app opens on the other device and responds there.

3 · Expose a service on a URL

When a service starts, the host registers a route for it. Local addresses always work and follow this shape:

<script>--<branch>--<project>.localhost

For example, a script named dev in the miniweb project on branch main is dev--miniweb.localhost.

  1. Add a serviceProxy block

    To reach a service from other machines, add a serviceProxy block under daemon in the host config with a publicBaseUrl.

  2. Point a wildcard DNS record at the host

    *.apps.example.com  →  <host address>
  3. Forward the Host header unchanged

    Any reverse proxy in front of Lyre must do this, because the host uses it to choose the service.

Exact fields

See the service-proxy reference for the config fields, forwarded headers and environment variables.

Read this before exposing anything

A public service URL exposes the workspace service itself. Go to the next section first.

Configuring a public base URL reserves aliases; it does not make them public. The host owner must choose Make public link… for the specific service. A visitor needs the link's access capability. The first browser visit redeems the single-use secret and sets a scoped secure cookie; copied bare URLs cannot grant access.

Use the script menu to stop the public link. Revocation closes its open WebSocket connections. Keep the app's own authentication and review what data it exposes.

It worked when

the explicitly granted link opens the intended service and an unauthorized bare URL is refused.

4 · Manage scripts without a terminal

Configured scripts can be listed and controlled by name:

lyre script ls
lyre script start <name>
lyre script stop <name>

Each command reports lifecycle, service port, proxy URLs, health, exit code and the supervised terminal id. Stopping a script ends its managed terminal rather than only removing the route.

An agent can do the same through the matching workspace-script tools, which require an explicit workspace id.

It worked whenlyre script ls lists your service and shows its port and health.

Security

Public service access is separate

A public service URL exposes the workspace service itself. The daemon’s password protects the daemon API and WebSocket; it does not protect a proxied development service.

  1. Use HTTPS at your reverse proxy

    For anything reachable outside your machine.

  2. Keep the service’s own authentication

    Do not rely on the proxy alone to decide who may use the app.

  3. Keep credentials out of client code

    And revoke or rotate anything that has been exposed.

Do not substitute a public URL

Do not expose a project’s development server publicly as a substitute for an authorized private preview. A public URL has a different access boundary.

You are safe to publish when

HTTPS is in front of it, the app checks who is using it, and no secret is in its client code.