What's New

​

July 2026

This month introduces parallel milestone execution, collaborative review, per-user daemon routing, and upstream sync — making large migrations faster to deliver and easier to coordinate across teams.

​

Parallel milestones

Milestones now declare dependencies on one another. When milestones are independent (no shared file dependencies), they can execute simultaneously — each on its own branch, each producing its own PR. Dependent milestones remain locked until their prerequisites merge. This means faster delivery without sacrificing PR review boundaries. You still review and merge each milestone individually; the difference is that independent work no longer waits in a queue. When a milestone merges while sibling branches are in progress, Morph detects whether those branches need to incorporate the new code and flags them as Rebase Required. Triggering the rebase is a single click — the agent handles the integration automatically.

​

Collaborative review

Multiple team members can now review the same milestone at the same time. Each reviewer gets their own independent review chat session — conversations, issue triaging, and resolutions don’t collide. When one reviewer resolves an issue or the agent applies a fix, Morph propagates the workspace changes to other active reviewers so everyone sees the latest code state. Chat sessions are locked to one active user at a time to prevent conflicting agent instructions, but multiple reviewers can browse issues and code in parallel.

​

Per-user ModelDaemon

For self-hosted daemon deployments, the routing model is now one daemon per user instead of one daemon per project. Each team member’s daemon handles that user’s work and runs one active job at a time — so multiple team members can work on the same project simultaneously without blocking each other. The daemon reports its status in real time: online, busy, or offline. If your daemon is busy, new requests queue until the current job finishes.

​

Upstream sync

Upstream sync is now fully available. When your team pushes changes to the repository’s mainline during the migration, you can trigger an upstream sync to incorporate those changes. This creates a sync milestone, updates the project baseline, and rebases any in-progress milestone branches — all handled by the agent.

​

June 2026

This month, we focused on making Morph more practical for real modernization work: stronger quality gates, more flexible project setup, smarter functional testing, better notifications, and expanded deployment options for restricted environments.

​

Acceptance Criteria

Acceptance Criteria bring measurable, automated quality gates to your code modernization projects. Instead of relying solely on builds and tests passing, you can now define custom checks - like performance thresholds, code coverage targets, benchmark results, or any quantifiable standard - that are automatically enforced before code is merged. Each Acceptance Criteria check is linked to your project’s lifecycle scripts and captures a baseline from the original codebase. As modernization progresses, every milestone review automatically validates that the modernized code meets the same, or better, quality bar as the original. If a check does not pass, the pull request is flagged before merge. To help you get started quickly, Morph can automatically discover relevant lifecycle scripts and suggested Acceptance Criteria based on your codebase’s structure and testing patterns. You can also create and manage Acceptance Criteria manually through chat. Acceptance Criteria are also visible during milestone review, so teams can see exactly which checks passed, which checks failed, and what needs attention before merge. 

​

Multiple projects per repository

You can now create multiple Morph projects from the same source repository. If you want separate modernization tracks, a maintenance project alongside an active migration, or different scopes on the same codebase. Each project still runs on its own feature branches and milestones, so work stays isolated even when the underlying repository is shared. When you create a project, the repo picker shows which other projects already use that repository, so you can make an informed choice. Morph handles setup efficiently behind the scenes, and removing one project will not disrupt another that shares the same source - your other projects, branches, and in-progress work stay intact.

​

Functional testing improvements

Morph’s functional testing workflows are now smarter across backend tests, frontend E2E tests, and projects where the application is already running.

​

Smarter backend functional tests

The backend testing agent now classifies features per endpoint rather than per repository when deciding what has pre-existing behavior to compare against. It also sets up reproducible test environments by seeding databases and running lifecycle scripts.

​

Frontend E2E test generation improvements

The frontend testing agent now detects and reuses existing Playwright suites in the target repository instead of scaffolding from scratch. It reuses the repository’s existing authentication setup, defaults to mocked APIs for stability, and captures results even when tests fail.

​

Connect to a running application

Morph can now connect to an already-running application instead of managing the application lifecycle itself. The testing agent understands connect mode: it verifies connectivity without attempting to restart the app.

​

Notifications

Morph now tells you when something is ready to review or input is needed. Five moments produce a notification:

• Your Project Spec is ready.
• Your Roadmap is generated.
• Your Lifecycle config is drafted.
• A milestone pull request is pending review.
• Morph is waiting for input

For each notification, you receive an email. If Morph is open in your browser, you also see an in-app banner in the top-right corner that takes you directly to the right project, milestone, or pull request.

​

On-prem and air-gapped Morph platform support

Modelcode now supports on-premise and air-gapped deployment of the Morph platform in Amazon Web Services, AWS GovCloud (US), and Google Cloud Platform. This gives customers more control over their environment by enabling independent deployments through Terraform scripts and deployment documentation. By removing dependencies on external cloud-hosted services like GitHub, Morph can support modernization workflows that need to run securely within isolated infrastructure. The platform uses Kubernetes for orchestration and Gitea as a self-hosted Git provider to manage code repositories locally. This architecture supports critical operations such as pull requests, comments, and milestone agent executions entirely within the customer’s network. It also handles the orchestration needed to seed initial tenants, provision administrative users, and automate Docker image bundling to streamline installation in restricted environments.

​

Gitea as an external provider

We’ve now added Gitea as a core Git provider, it adds support for customers who cannot use cloud-hosted platforms like GitHub because of network restrictions, compliance requirements, or air-gapped environments. For these customers, Morph provides its own Gitea instance as the code-hosting layer, giving teams a fully functional Git workflow without requiring external connectivity.

​

May 2026

​

Multi-repo support is generally available

The Morph Platform now supports many-to-many modernization projects across multiple source repositories and multiple target repositories. This is especially important for enterprise backend modernization projects where the application is spread across services, shared libraries, APIs, generated clients, and separate target applications. What changed

• The Morph Platform can support many source repos to many target repos.
• Modernization projects can include multiple related codebases.
• Backend modernization workflows can better reflect real enterprise application structures.

Why it matters Most enterprise systems do not live in one clean repository. Multi-repo support allows the Morph Platform to work across the actual shape of customer software instead of forcing teams to simplify their architecture before starting a modernization project.

---

​

ModelDaemon

ModelDaemon introduces a more secure and scalable execution model for customer environments. MD runs inside the customer’s infrastructure using outbound-only connectivity. the Morph Platform continues to orchestrate the work, while execution happens closer to the customer’s code, dependencies, tools, and internal systems. What changed

• ModelDaemon runs inside the customer environment.
• Connectivity is outbound-only.
• The Morph Platform can execute work closer to private code, private dependencies, and internal infrastructure.
• The daemon now supports smarter execution through the morph-agent at the edge.

Why it matters Customers do not need to expose inbound access or move private code and dependencies outside their environment. This makes the Morph Platform more practical for enterprise and regulated deployments.

---

​

Smarter local execution with morph-agent

With ModelDaemon, the daemon is no longer just a remote command runner. The morph-agent can run full LLM-driven and it allows the agent to reason through dependencies, make code changes, run commands, execute tests, and handle workflows directly inside the customer’s infrastructure. What changed

• The daemon can run LLM-driven execution loops locally.
• Code changes, dependency handling, and workflow execution can happen inside the customer environment.
• The Morph Platform orchestration coordinates the work while the daemon performs richer local execution.

Why it matters Enterprise projects often depend on internal services, private packages, local tooling, and environment-specific setup. Smarter local execution helps the Morph Platform operate in those environments with fewer assumptions.

---

​

Distributed and scalable execution architecture

ModelDaemon also moves the Morph Platform toward a more distributed, async, event-driven execution architecture. This replaces the older tightly coupled Docker-control model with a more flexible execution system based on parallel workspaces and event-driven coordination. What changed

• Execution is now more async and event-driven.
• Parallel workspaces improve flexibility and scalability.
• The Morph Platform is less dependent on tightly coupled Docker control paths.

Why it matters Large modernization projects need execution infrastructure that can handle long-running work, retries, partial progress, and customer-specific environments. This architecture gives the Morph Platform a stronger foundation for more complex projects.

---

​

Improved ModelDaemon setup experience

The Morph Platform now provides a more continuous setup and execution flow for ModelDaemon projects. Instead of requiring users to complete a rigid multi-step configuration process, the Morph Platform can analyze the repository, detect dependencies, identify missing metadata, and provide clearer next-step guidance during execution. What changed

• Repo analysis is more integrated into setup.
• Dependency detection is clearer.
• Missing metadata is surfaced earlier.
• Execution progress is streamed with better guidance.

Why it matters Modernization often starts with the hardest question: “How does this application actually run?” These improvements help the Morph Platform guide users through setup instead of requiring perfect configuration up front.

---

​

Robust functional testing

The Morph Platform can validate parts of your application, such as APIs and services, and continue making progress even when some dependencies are missing. What changed

• Missing dependencies no longer have to block all progress.
• The Morph Platform can continue useful work even when the full environment is incomplete.

Why it matters Enterprise environments are rarely perfect on the first run. Partial execution helps teams avoid all-or-nothing failures and continue moving forward while missing dependencies are identified and resolved.

---

​

Clearer errors and chat driven resolution

The Morph Platform now provides clearer explanations for configuration and lifecycle command errors. For common setup issues, the Morph Platform can suggest a fix, apply it, and retry execution through chat. What changed

• Configuration errors are easier to understand.
• Lifecycle command failures include clearer explanations.
• Common issues can be resolved with the Morph agent
• The Morph Platform will automatically retry execution after applying a fix.

Why it matters Setup issues will still happen, especially in large enterprise applications. The goal is to make those issues less manual, less mysterious, and less likely to stop a project.

---

​

Frontend modernization support

The Morph Platform now includes early support for frontend modernization workflows. Why it matters Many modernization projects are not purely backend. They include server-rendered templates, embedded frontend logic, and older UI frameworks that need to be separated from backend business logic. This release is the first step toward broader frontend stack support.

---

​

Azure DevOps support

The Morph Platform now supports Azure DevOps. This expands the environments where customers can connect the Morph Platform to existing source control and delivery workflows. What changed

• Added Azure DevOps repository support.
• Enabled the Morph Platform project setup for Azure DevOps-based customers.
• Completed support for HealthEquity and RadarHealth workflows.

Why it matters Many enterprise teams use Azure DevOps as their primary development platform. This update removes friction for customers who want to use the Morph Platform without changing their existing source control workflow.

---