Lifecycle Strategy

During onboarding asks how the agent should access your app. This is the lifecycle strategy, and it determines whether brings your application up itself or talks to an instance you keep running. The choice shapes how lifecycle scripts, health checks, and functional testing work for the rest of the project.

​

Why the agent needs runtime access

modernizes your code. A lot of that work can be done statically — reading the source, reasoning about it, and rewriting it. But code that only looks correct on paper isn’t enough. When the agent can actually run the application and observe its behavior at runtime, the quality of the results goes up substantially: it validates changes against a working app, catches regressions early, and uses functional tests to confirm the modernized code behaves like the original. That runtime access has two requirements:

• Access to the origin application - so the agent can observe the original behavior and use it as the baseline it modernizes toward. You grant this with one of the two strategies below (connect or managed).
• Access to external services and dependencies - databases, internal APIs, message queues, private registries, and anything else the app talks to. The target (modernized) application needs these at runtime just as the origin does, so the build environment must be able to reach them.

---

​

The two strategies

• Morph runs your app (managed) - installs, builds, runs, and tears down your application from source, owning its lifecycle on every run.
• You run your app (connect) - You keep the application running, up, and reachable yourself, and the agent connects to that live instance.

The trade-off is setup speed vs. ownership: connect is much faster to set up, but you take care of running the app — keeping it up and tearing it down stays your responsibility; managed can take longer to set up, but after that takes care of running the origin app for you.

---

​

Morph runs your app (managed)

With the managed strategy, takes care of running the app — it owns the full lifecycle: running it, keeping it up, and tearing it down. The agent automatically discovers the install, build, and run scripts by analyzing your codebase, then uses them to start your application from source inside the build environment. runs the health check and test commands against the app it started. You review the discovered scripts and correct them if needed — you don’t author them from scratch. Setup can take a little longer here, because the agent has to discover and validate how to build and run the app before the project starts. The payoff is that you hand the origin app’s lifecycle to : it brings the app up from a known, reproducible state on every run and tears it down afterward, so you don’t have to run or keep anything up yourself. Even though runs the app for you, the external services and dependencies your app relies on — databases, internal APIs, message queues, private registries, and so on — still need to be running and reachable from the build environment. The agent can build and start your app, but it can’t stand up the infrastructure behind it. Choose this when:

• can build and run your app from source.
• You are comfortable setting up the environment yourself.

Because every run starts from a known, reproducible state, this strategy gives the agent the most control over the application and a consistent baseline to test against.

---

​

You run your app (connect)

With the connect strategy, you take care of running the app and does not build or run it. Instead, you point it at an application that is already running on your infrastructure, and the agent interacts with it directly over its base URL. Install, build, and run steps are skipped; the agent only probes the running instance via a health check. This strategy is only available with the Self Hosted build environment, because the ModelDaemon has to be able to reach the running app from inside your network. Setup is much faster because there’s nothing to discover, build, or validate up front — you just provide the URL. The trade-off is that the origin app’s lifecycle stays your responsibility: only probes the instance you point it at, so running it, keeping it up and healthy, and tearing it down for the duration of the project is on you. You provide:

• Base URL - The root URL where your application is accessible (for example, http://localhost:8000).
• Health Check Command - A command that confirms the app is reachable and healthy (for example, curl -f http://localhost:8000/health).
• External services and dependencies - The databases, internal APIs, message queues, private registries, and any other services your app talks to must be running and reachable from the build environment. The target (modernized) application needs them at runtime just as the origin does.

Choose this when:

• Your application is already deployed and running, and you want the agent to work against that instance.
• You want to get started quickly and are comfortable keeping the origin app running yourself.
• Building or running the app from source inside the build environment is impractical (for example, it depends on infrastructure the build environment cannot reproduce).

---

​

Which should I pick?

Pick based on the trade-off above: connect gets you started fastest if you already keep the app running, while managed hands the origin app’s lifecycle to once it’s set up.

---

​

Related Docs