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.
-
Open the Scripts section
From the workspace menu choose Show setup (in Guided mode that menu is called More), then open the Scripts section.
-
Add a preview service
Choose Add script, name it
preview, enter the command that starts your frontend, and turn on Run as a service. -
Add a backend on a different port
If your app has a separate backend, add a service named
backend,apiorserver. Lyre starts one named companion before the frontend you chose. -
Save and start
Save the project’s settings, then start the app from the workspace’s app/service control.
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.
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. |
-
Keep the host ready
Leave the computer awake with Lyre running. If it is unreachable, the device cannot start the app.
-
Open the app on the device
Use Apps on the paired device. See connectivity and testing from another screen.
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.
-
Add a serviceProxy block
To reach a service from other machines, add a
serviceProxyblock underdaemonin the host config with apublicBaseUrl. -
Point a wildcard DNS record at the host
*.apps.example.com → <host address> -
Forward the Host header unchanged
Any reverse proxy in front of Lyre must do this, because the host uses it to choose the service.
See the service-proxy reference for the config fields, forwarded headers and environment variables.
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.
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.
lyre script ls lists your service and shows its port
and health.
Security
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.
-
Use HTTPS at your reverse proxy
For anything reachable outside your machine.
-
Keep the service’s own authentication
Do not rely on the proxy alone to decide who may use the app.
-
Keep credentials out of client code
And revoke or rotate anything that has been exposed.
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.
HTTPS is in front of it, the app checks who is using it, and no secret is in its client code.