Duolingo simplifies self-service infrastructure with Temporal Nexus

The customer

Duolingo is the world’s most popular language-learning app, with hundreds of millions of learners worldwide. The company’s mission is to develop the best education in the world and make it universally available. Duolingo offers a gamified, mobile-first approach to learning languages, as well as other subjects like math, music, and most recently chess, by using bite-sized, interactive lessons that incorporate spaced repetition and AI-backed teaching methods.

Why Temporal?

At Duolingo, the Cloud Operations team is responsible for their infrastructure running on AWS, ensuring reliability and enabling engineering productivity at scale. They work to develop tools that allow engineers to build learner-facing features quickly and safely, while providing guidance on deploying, monitoring, and managing production services, databases, and other critical systems.

Duolingo first adopted Temporal for critical use cases like disaster recovery and RDS lifecycle operations, but the true inflection point came with Temporal Nexus. Nexus allows Temporal Workflows to cross Namespace boundaries reliably, making it possible to expose Cloud Operations–owned Workflows to other teams without compromising security or control. This capability turned Temporal from a lesser-known tool used almost secretly just by the Cloud Operations team and a few platform teams into the foundation for Workflow-as-a-service across Duolingo.

The challenge

The Duolingo Cloud Operations team manages Workflows that are useful for other teams, and these Workflows often include critical steps requiring approvals or manual intervention. The challenge they initially faced was providing developers with the ability to trigger specific Workflows, but in a secure way that did not expose controls.

One of the options the team considered was operating out of a single monolith Namespace. If everyone on their team operated in this capacity, other teams would be allowed to freely trigger and even modify critical steps. However, security and control become a challenge with monolithic Namespaces, as the entire organization shares the same level of access.

If they used isolated Namespaces, Duolingo’s Cloud Operations team would have previously needed to build a custom integration, like an extra API layer, and handle retries, failures, and other reliability logic. These solutions often come with significant drawbacks, such as increased maintenance overhead, excessive boilerplate code, and reduced reliability.

Because neither approach is ideal, Duolingo needed a solution that preserves the benefits of isolated Namespaces and provides robust cross-Namespace Workflow orchestration.

The intermediate solution was to make the Workflow internal, but Cloud Operations still needed to copy and paste parameters from help requests submitted to the team. This reduced some manual toil but still left Cloud Operations as both trigger and approver — a bottleneck and a scaling barrier.

The solution

Temporal Nexus, a new feature announced in December 2024, extends the managed, Durable Execution model of Temporal across Namespaces, allowing customers to do the following:

• Workflows in Namespace A can trigger workflows in Namespace B via Nexus Endpoints, with Temporal managing retries and handling failures automatically, just like intra-Namespace calls.
• Expose only what’s needed to other teams. Engineers in Namespace A can trigger workflows in Namespace B without gaining unnecessary control over critical steps or internal details.
• External teams track the progress of triggered Workflows without granting them full access or the ability to modify underlying processes.

While Nexus provided the backend foundation for secure cross-Namespace orchestration, Duolingo’s Cloud Operations team also needed a way to make Workflows discoverable and accessible to engineers across the company. To achieve this, they built a self-service Workflow portal on top of Nexus. The portal serves as an entry point for engineers to browse, understand, and trigger available Workflows. Each Workflow is defined using a JSON configuration (capturing parameters and schemas) and documented with Markdown guides. This approach allows backend and platform engineers — many of whom have little to no frontend experience — to add new Workflows without writing UI code. By simply contributing JSON and Markdown, engineers extend the portal organically, ensuring it evolves with the organization’s needs.

To connect the portal with Temporal, the team built a gateway microservice. The microservice exposes Workflows over HTTP, receiving trigger requests from the portal. It starts Workflows in a shared namespace, which then securely invokes the appropriate Workflow in the target team’s Namespace via Nexus.

Opening Workflows for self-service also required strong guardrails:

• Approval steps: Sensitive actions pause until the Cloud Operations team explicitly approves them, with approval requests routed through Slack.
• Fine-grained IAM policies: Temporal Workers operate under tightly scoped IAM roles. For example, a Worker that resizes RDS clusters cannot delete AWS accounts.
• Slack notifications: Engineers stay informed through notifications in Slack, while the Cloud Operations team can step in at the right moments.

With this foundation in place, the Cloud Operations team began exposing more Workflows through Nexus. Engineers could now self-serve for many common tasks, while the Cloud Operations team retained control over sensitive actions. This unlocked the ability to build a secure, scalable self-service system that both empowers engineers and protects critical infrastructure.

The results

Temporal Nexus has had a transformative impact at Duolingo by enabling true self-service for engineers. Tasks that once required waiting on Cloud Operations for manual intervention can now be completed in minutes. Engineers trigger Workflows independently, see immediate results, and collectively save hundreds of hours. Already, Cloud Operations and more than six other teams have built over 20 self-service Workflows supporting diverse use cases across the organization in just a few months.

This self-service foundation has accelerated the adoption of Temporal. Since the launch of BootstrapTemporalWorkflow — a self-service Temporal Workflow that bootstraps new Workflows using Temporal itself — over 20 engineering teams have used it to create their own Temporal Cloud Namespaces. Many of these now run production workloads across a wide range of scenarios. By fully automating boilerplate setup, engineers can typically run their first Workflow locally within minutes and deploy to production in just one or two days if the logic is not too complicated. As a result, many teams are now considering Temporal as a key enabler in achieving their future OKRs.

Nexus also pushed Duolingo to think about the future of Workflow-as-a-service, in much the same way APIs are exposed today. While Duolingo originally adopted Temporal primarily as a script runner for multi-step and long-running workflows, they can now envision a future where teams build various types of Workflows and seamlessly share them through Nexus.

The takeaways

Duolingo can now leverage Temporal Nexus to enable Workflow-as-a-service, empowering engineering teams with self-service capabilities:

• Autonomy with control: Engineers can trigger Workflows from their own or shared Namespaces, while the Cloud Operations team keeps control over critical approval steps in our Namespace.
• Reliability built-in: Cross-Namespace calls leverage Temporal’s native reliability (Retries, state preservation) without custom mechanisms.
• Secure visibility: Teams can track Workflow statuses without direct access to specific processes.

As a result, engineers gain full self-service capabilities — they can trigger our Workflows and track their progress — while Duolingo retains ultimate authority and security. This design pattern is the cornerstone for building a scalable and secure self-service ecosystem at Duolingo.

Temporal Nexus transformed Duolingo’s Cloud Operations team’s Workflows into a secure self-service platform for the entire organization. The combination of the self-service portal and Nexus-powered Workflows boosted engineering productivity, automated complex jobs, and reduced bottlenecks — while accelerating company-wide Temporal adoption.

Looking ahead, Duolingo plans to do the following:

1. Move Nexus to Python: Today, Nexus logic is implemented in Go while most Workflows are in Python. Consolidating will simplify development for their team.
2. Workflow-as-a-service: Provide reusable Nexus operations (Slack, JIRA, etc.) that “just work” like RPCs without token or API management.
3. Deeper Slack integration: Today, Slack is used only for notifications, but approvals are still handled separately via Signals on Temporal UI. The future plan is to bring approvals and full human-in-the-loop interactions directly into Slack, making Workflows even easier to monitor, approve, and control from the chat interface engineers already use.
4. Improving infrastructure around Temporal: Further improve the bootstrapping experience for Temporal beginners, build better observability tooling, establish best practices for different Workflow patterns, and provide commonly used utilities and libraries to accelerate adoption across teams.

Looking to build your own self-service infrastructure with Temporal? Start today with a free trial of Temporal Cloud and get $1,000 in credits. And if you want to leverage Temporal Nexus to reliably connect Temporal Applications across any boundary, you can get started by:

• Building your first Nexus service using the Go SDK, Java SDK, or Python SDK quick-start guide.
• Evaluating use cases for Nexus and watching the Nexus keynote and demo.
• Joining the #nexus community channel in our Community Slack.