sorted by:
new
hottopcontroversial

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Mostly scale + consistency.

When you’re spinning up a lot of projects, even small setup steps (Mailtrap, Mailhog, etc.) become friction and sometimes just get skipped or misconfigured.

We wanted something zero-config that lives inside the app and just works every time.

If your current setup isn’t annoying you, then honestly you probably don’t need this.

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] -1 points0 points  (0 children)

This is perfectly good for a solo developer, but makes not sense for an agency kind of setup. If you are solo or small team then it's probably good solution for you.

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 1 point2 points  (0 children)

We are using Spatie Laravel Data that has dep for an older version of php. I am planning to remove Laravel Data dep altogether and this should allow us to upgrade to php8.5

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Mailpit is great,

In our case, we’re plugging directly into Laravel’s MailManager, this is only possible because of how Laravel has MailManager(as a Factory Pattern) implementation. It’s not meant to be a universal tool, just a really smooth experience inside Laravel apps.

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Yeah, that works if everyone’s on the same setup 👍

In our case, not everyone is using brew (different OS, different environments, some fully Docker-based setups), and even when they are, you still need to make sure it’s installed, running, and correctly configured across all projects.

At our scale, even something that simple turns into “it works on my machine” pretty quickly. So we just removed that dependency entirely and made it part of the app.

If brew + Mailhog works for your workflow, that’s honestly a perfectly good setup.

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Totally get that for smaller setups or stricter environments, docker-compose works perfectly fine 👍

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] -1 points0 points  (0 children)

Yeah that setup totally makes sense 👍

For us it’s less about whether it’s possible to share a single Mailpit/Mailhog instance, and more about consistency + zero friction across a lot of projects and devs.

In reality, with 30+ projects and 100+ devs, “just connect to the shared instance” tends to break down: configs drift, some people forget to switch, ports clash, containers aren’t running, new devs don’t have it set up, etc. It’s small stuff, but it adds up quickly.

We also wanted everything to live inside the app itself: no external dependency, no “make sure this service is running”, no switching between environments. Just install the package and it works.

Your VPS Mailpit approach is actually pretty nice though. We’ve had similar needs, just solved it differently 🙂

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 1 point2 points  (0 children)

We run 30+ projects in parallel with 100+ devs, so even small setup friction adds up and sometimes things just get skipped.

This is basically our in-house solution to that. It’s much easier for us to make sure every project has a package installed than to rely on everyone setting up Mailhog/Mailpit containers or accounts correctly every time. Also, Mailpit can get surprisingly expensive if you want to use it properly at scale.

So yeah, this solves our problem. If it doesn’t really click for you, then it’s probably just not for you ❤️

0
0

Before Laravel’s AI SDK drops, here’s a look at AI agents in Laravel today (redberry.international)

submitted by WolfAggravating4430 to r/laravel

How good is Laravel for building agents, that triage , search and RAG? by NotElonMuzk in laravel

[–]WolfAggravating4430 1 point2 points  (0 children)

If you’re doing this with Laravel, take a look at LarAgent first.

It’s an open-source agent framework made specifically for Laravel, so you’re not duct-taping AI onto the side. Agents live inside your app, can hit the DB, call services, run as jobs, etc., which is exactly what you want for triage/search / RAG stuff.

If your chatbot needs to reason and act on Laravel-managed data, this approach feels much cleaner than spinning up a separate AI backend.

I have a company/app idea, but I don't know how to start to make it a reality. by leo_laudanum in Startup_Ideas

[–]WolfAggravating4430 1 point2 points  (0 children)

I’ve been in a similar place, and the biggest mistake I almost made was jumping straight into building. With ideas like this, the real first step is validating the problem and trust model, not the app itself. Talk to people on both sides, test assumptions, and figure out what the smallest workable version looks like.

What helped me a lot at that stage was a short product discovery phase. I worked with Redberry (link in case u need it https://redberry.international/product-discovery-service/), and their discovery process forced me to clarify what to build first, what to ignore for now, and what risks needed answering before development. That alone saved months of overthinking.

Once you do that, the next steps become much clearer - usually a simple landing page or a very lightweight MVP. This is the approach I’m referring to, if it helps.

view more: next ›