How Trybe halved response times on Laravel Cloud

The number that surprised Trybe's Head of Engineering most about migrating to Laravel Cloud was 2.5 seconds.

As a company that designs cloud-based software for spas and hotels, Trybe's slowest API endpoints do heavy work. They run availability checks across large date ranges and loop over inventory to answer one question: can a guest actually book this treatment at this time? On Laravel Vapor, those endpoints took around five seconds at Trybe's busiest sites. That is a long time to stare at a spinner on a booking page.

Dan Johnson, Head of Engineering at Trybe, expected the migration to hold Trybe's numbers steady. He didn't expect the numbers to improve on their own. The team moved the application to Laravel Cloud, and response times dropped to about 2.5 seconds.

"We didn't make any changes. We just moved the application to Laravel Cloud, and that went down to half the time. That's down to more efficient resources powering our platform,” said Dan.

To hear the story from Dan himself, watch our live session. Here is the rest of what changed.

Vapor to Cloud migration results

• The team saw 17% lower compute costs compared to running the same workload on AWS directly.

• 96 database queries were reduced to 12 on a single request, once Laravel Nightwatch made the pattern visible.

• Cache calls on a hot path were cut by roughly 100x, for the same reason.

• The platform can process 2.7 million jobs per day on Laravel's managed queues, with workers scaling up and down automatically.

• Three isolated environments migrated with zero downtime, including a phased 1% to 100% ramp on production traffic.

Moving off Vapor yourself? Start with the Laravel Vapor to Laravel Cloud migration guide.

About Trybe

Trybe runs the booking, membership, payments, and shopfront software behind more than 400 spa and hotel properties. Today, the platform handles 500 million requests a month, can easily process 2.7 million jobs a day, and runs 1,440 scheduled tasks a day, one every minute. Its primary database is 1.6 TB of MongoDB (833 GB compressed) hosted in Ireland.

Every booking in Trybe’s platform begins with a medical intake form: allergies, medications, treatment history, everything the therapist needs before performing a service. That data is regulated as private medical information.

Protecting it is a hard product requirement, and it is why Trybe chose Laravel Private Cloud. Sharing infrastructure between staging and production is a liability when the data is medical. Private Cloud gave Trybe fully isolated environments and the compliance posture the business depends on.

Why Vapor stopped fitting

Trybe originally chose Laravel Vapor because they did not want to think about infrastructure. That worked when the team had one UK customer and traffic dropped to near-zero overnight, but it doesn’t scale.

"We don't really want to be working around the infrastructure. We just want to be writing code, shipping the application."

Two things forced the conversation as Trybe grew: first, long jobs kept hitting Lambda's timeout, which meant data exports had to be chunked in application code and stitched back together at the end. Dan did not want to keep writing around the platform.

Second, the cost model inverted. Pay-per-request is cheap when traffic dips overnight, but becomes expensive when 500 million requests a month arrive on a global 24/7 pattern.

When Laravel Cloud shipped Private Cloud, the timing lined up.

The architecture Trybe could not simplify away

Trybe's architecture is complex. Behind a single domain, api.try.be, four separate applications route by path:

• api.try.be/shop to the shop API (which also serves every one of Trybe's 400 white-labeled shopfronts on wildcard subdomains)

• api.try.be/customers to the customer API

• api.try.be/inventory to the inventory API

• api.try.be/* as a catch-all to the Auth API

Behind those apps sit 12 running application instances across three environments, an ElastiCache Redis cluster, a MySQL database on Amazon RDS, and a 1.6 TB MongoDB database on MongoDB Atlas that could not move.

Trybe did not refactor any of it before the migration.

Three separate Private Clouds, because medical data needs real walls

Trybe does not run three environments inside one cluster. They run three completely separate Private Clouds, one each for staging, playground, and production. They have different VPC (virtual private cloud) networks and different ElastiCache instances to eliminate shared surface area.

"There's no way that anything on staging or playground can impact the production environment in terms of data,” explains Dan.

Playground is the environment that stands out, and a use case the Laravel Cloud team doesn’t see often. It is a true sandbox, and Trybe's sales team uses it live during prospect demos. Third-party developers integrating against Trybe's public API build against it. It only works because the playground has its own fully isolated Private Cloud. Otherwise, every demo would be a data leak waiting to happen.

The 1.6 TB database Trybe could not move

Laravel Cloud does not offer managed MongoDB, and moving 1.6 TB of it was off the table.

The answer was VPC peering (a private network link between two VPCs) between each Private Cloud and MongoDB Atlas. Two things had to be resolved during setup, both by the Laravel Cloud team:

• Trybe's existing AWS accounts had overlapping CIDR (Classless Inter-Domain Routing) blocks. That would have forced expensive VPC endpoints. Laravel Cloud provisioned all three environments with non-overlapping blocks.

• Laravel Cloud's Kubernetes cluster ran IPv6 with NAT64 translation, which Atlas does not support. The Cloud team pushed a Terraform DNS (Domain Name System) tweak across all three environments to force IPv4 resolution.

Trybe kept its data where it lived. Laravel launched an Ireland region (EU-West-1) so the application could sit next to it.

How Trybe moved 500 million requests a month without downtime

Trybe's migration philosophy was cautious, methodical, and zero-downtime. Platform stability is not negotiable when the data is medical, so the team built the migration around gradual traffic ramps and let observability decide when to move forward.

Trybe migrated their platform in this order:

1. Staging: 50% of traffic to Cloud, 50% still on Vapor via AWS Route 53 weighted DNS records. Once Nightwatch stats looked healthy, they pushed staging to 100%.

2. Playground: Same weighted DNS approach, same Nightwatch-driven validation. Once the sandbox was clean, it moved fully to Cloud.

3. Production: This one started at 1% of traffic. 1% of 500 million requests a month is still five million requests, more than enough to surface real problems before they became customer-facing ones. From there, Dan’s team ramped carefully, watching Nightwatch at every step.

Production has been running clean at 100% on Laravel Cloud for several months now.

Support that pays for itself

For Dan, the biggest ongoing value of moving to Laravel Cloud has been the Advanced support plan, an option that wasn’t available to them on AWS. Direct Slack access to the engineers who build both the platform and the framework changes what "support" means day-to-day.

"The whole team has noticed how it's been incredible having the support plan. We get a response within one minute, and we get the best engineers in the world jumping on this problem with us."

That access has already paid off. When Trybe recently hit an incident, the Laravel Cloud team jumped into the Slack channel, identified the root cause, and pointed the team to the fix. "If it wasn't for Laravel Cloud support finding that out for us, we would have been going around in circles for hours."

What else changed

From microservices and Vercel to one monorepo

Trybe used to run a set of microservices alongside a Vercel-hosted Next.js documentation site. Both are gone. The microservices consolidated into a single Laravel monolith and the Next.js docs moved into the same repository, all deployed on Laravel Cloud through its monorepo support. The Cloud team converted Trybe's existing application in place, because the dashboard did not yet expose the monorepo switch.

"That probably wasn't something that we could have done with Laravel Vapor. Now we've got a monorepo, which is enabling us to ship faster."

Pointing Cloud at the docs subdirectory was enough for it to recognize the Next.js project on its own. A non-standard configuration on Trybe's side needed a small assist from the Cloud team. Without that quirk, Dan says the whole move would have taken under five minutes.

"I picked the directory for the documentation, and it was like, cool, that's a Next.js project, here you go, done. It was super easy."

Managed queues

Trybe was a launch customer for Laravel's managed queues. In one recent seven-day window, they processed 9.7 million jobs, with workers scaling up and down automatically without Lambda timeouts to design around. "We were promised that we wouldn't notice any difference. It would just work fine. And it did,” says Dan.

RBAC (role-based access control)

Fine-tuning permissions on AWS IAM (Identity and Access Management) is famously challenging. “[On Laravel Cloud,] it's just as simple as it should be. I can create a user, tick what I want to allow them to do, and it just works."

Try Laravel Cloud

Trybe moved 500 million requests a month, three isolated environments, a 1.6 TB database they could not move, and a medical-grade compliance posture onto Laravel Cloud. Their slowest endpoints run twice as fast. Their compute costs are 17% lower. They did not drop a request in the process.

On Vapor and thinking about the same move? Start with the Laravel Vapor to Laravel Cloud migration guide. Need the isolation Trybe needed? See Laravel Private Cloud.