# Changing it after people are using it > The first version is rarely the one people keep. This is what the second and third look like when someone is already using the link you sent. Part of the reachpad docs: https://reachpad.dev/docs. Rendered page: https://reachpad.dev/docs/changing. Last checked 2026-08-22. ## The link is the address, not the build A link from `ports expose` points at a port in a workspace, not at a copy of what was running when you sent it. Rebuild the app, restart it on the same port, and the same link serves the new version. Nobody needs to be sent anything again. ```bash # already exposed, already sent to someone reachpad ports expose 3000 # ... the agent changes the app, you restart it on 3000 ... reachpad ports expose 3000 # same link back ``` Re-running `expose` on a port that is already open returns the link it already has rather than minting a second one, so it is safe to run again when you are not sure of the state. > Note: `ports revoke` is the one thing that breaks the address. A revoked link never comes back, and re-exposing the same port afterwards mints a different one. If the person you sent it to should keep their link, do not revoke it. ## Making the change The change happens in the workspace that is already serving it. That is the point of the workspace outliving the session: the repository, the installed dependencies, the database and its rows, and whatever the agent learned about the project are all still there, so the second request starts where the first one finished rather than from a clone. Attach, tell the agent what to change, restart the app on the same port. If you had paused the workspace, `attach` boots it from the sealed disk first. What survives that pause and what does not is [persistence](https://reachpad.dev/docs/persistence). ## What breaks while you do it Be straight with whoever is holding the link, because this part is visible to them. - While the app is stopped, the link returns an error rather than an older version. There is no second copy still serving, so a restart is a short outage and not a rollout. - A paused workspace does not answer at all: `run` and `attach` wake one, a visitor's request does not. Resume it before you send the link. - Anything the app kept only in memory is gone after a restart. Rows in a database on the workspace disk survive; a cache does not. > Note: This is a preview link with a stable address, not a production deployment. If people are depending on it being up while you change it, that is the signal you have outgrown what this page describes. ## Trying a change without risking the one that works When the change is large enough that you would rather not make it in the workspace people are pointed at, fork the workspace, change the copy, and expose a port on the fork. The fork gets its own link, so the original keeps serving while you work. ```bash reachpad fork reachpad ports expose 3000 ``` A fork starts from a snapshot of the disk and counts against your workspace limits like any other. Branching and moving one back in time are covered in [forks and rewind](https://reachpad.dev/docs/forks). ## When a link is not enough A port link lets someone use the app. It does not let them see the code, the terminal or the data. When the person asking for changes should be able to make them, share the workspace instead: a collaborator can drive the terminal and the agent in it, and a viewer can watch without typing. Both are covered in [sharing a workspace](https://reachpad.dev/docs/sharing).