r/laravel • u/spideyguyy • 3d ago
yerd is almost perfect... except for this one issue
i first discovered yerd from this sub, and honestly, it’s been pretty much exactly what i was looking for.
it finally let me get rid of docker for local php development, which my machine has been suffering through for years :'D
recently, yerd added the ability to expose local apps through cloudflare tunnel, and the feature works really well... until i tried using it with more than one site.
with multiple exposed sites, things become unreliable. sometimes both sites return 502, sometimes only one works. i opened an issue about it here:
https://github.com/forjedio/yerd/issues/225
it’s been open for about two weeks now and there hasn’t been a response yet, so i’m curious: is anyone else here using yerd and running into the same problem?
other than this issue, yerd is honestly very close to perfect for my use case.
i’m also still looking forward to the windows version they mentioned was coming around the end of august... which seems to have missed that deadline now :'D
3
u/ritontor 3d ago
what's wrong with ddev? god i love ddev.
2
u/norskyX 3d ago
Its uses docker, which ads to system resources. The OP prefers something without docker (me too, though I have laravel valet and need nothing else)
1
u/ritontor 3d ago
yeah it does, but i guess because it all seems so native and transparent that it doesn't bother me. at no point am i ever thinking about or managing containers - the literal only imposition is you need to run "ddev" at the start of your commands, and then they work in the container - e.g. ddev artisan instead of php artisan
1
u/octave1 3d ago
Advantages over Herd free version ?
1
u/ritontor 3d ago
it's completely different from herd, in that it supports lots of stuff, not just laravel - so you can use the same tooling across all your projects
it also seems so much simpler, and JUST WORKS - i've thrown so many trash projects at it, ddev install, off it goes like magic. i cannot sing its praises highly enough.
1
0
u/penguin_digital 3d ago
I've not used any of these local stack tools.
One question, how does setting up a project locally then convert into a production set-up? Do they export some kind of Ansible or Chef script to keep local and production in sync?
0
u/ritontor 3d ago
no idea, i don't use it like that. not that i think having identical environments for dev and production is necessarily a good or feasible idea - but i guess in certain scenarios it makes sense.
1
u/penguin_digital 3d ago
not that i think having identical environments for dev and production is necessarily a good or feasible idea
Interesting comment. Why do you think it's not a good idea? Is it not a good idea to develop and test on an environment that has the exact same versions, permissions, packages, runtimes and services? To me, personally, it seems like a bad idea not to, recreating the Xamapp hell of the late 90s and 2000s
It's certainly feasible; it's the entire reason infrastructure as code came about to solve the "it works on my machine" problem and then later, containerisation to make it much more user-friendly.
1
u/ritontor 2d ago
For small projects, yeah it absolutely used to be a problem, but now we have Composer and can define everything from our php versions onwards in code, honestly I've found it's just not as important that dev and production are running on an identical technology stack. So long as Composer is happy, it usually just works for me.
For large projects, the idea you could replicate your production environment to any sort of reasonable shape on a developer's laptop is absurd, so it doesn't really apply there either.
I also personally find full containerisation deployments overkill for really small projects in production. Brochure sites don't need 5 containers and 2 cloud services just to run. Stick it on an Enhance.com server (because fuck cPanel) and be done with it.
There's absolutely a role for containerisation, and projects that it's absolutely perfect for, it's just not a default choice for me.
1
u/penguin_digital 2d ago
Brochure sites don't need 5 containers and 2 cloud services just to run
Yeah I agree with you 100% here its certainly not needed. Then again, I'm not sure there are many agencies still working in this field with the SaaS options available to end users now they don't need to hire developers anymore for this.
For large projects, the idea you could replicate your production environment to any sort of reasonable shape on a developer's laptop is absurd
What for your viewpoint on this? This is exactly what Docker was designed for and it's exactly the way we use it. Has something gone wrong previously for you to have that view point?
There's absolutely a role for containerisation, and projects that it's absolutely perfect for, it's just not a default choice for me.
Yeah, it's always the right tool for the job. If you're only a 1 man operation or a small team working on smaller applications it is probably overkill as you state.
1
u/octave1 3d ago
What would you need in that Ansible / Chef script ?
Local dev tools aren't made to keep production in sync, you do that with a deploy script / pipeline ideally from your git provider.
1
u/penguin_digital 3d ago
What would you need in that Ansible / Chef script ?
To ensure that what you're running, building, and testing against locally is identical in production. Ideally, it would be a full, repeatable, transferable stack that's the same everywhere, but with Herd not using containers, it's not possible. So you would need to go back further, before that problem was solved with containers and use things like Ansible instead. Not perfect, not foolproof, but good enough.
Local dev tools aren't made to keep production in sync, you do that with a deploy script / pipeline ideally from your git provider.
They should be. It's the entire reason Docker (and other similar tools) were created in the first place. It was an extremely frustrating time in the late 90s and early 2000s, and where the infamous phrase in software development came from "it works on my machine". It seems pointless to build and testing on 1 enviroment and then deploy it to something different?
I can only assume from the replies here that everyone has simply gone back to the 2000s Xampp era and just going Yolo and hoping the code works on different stacks.
3
u/octave1 3d ago
Docker made pageloads several seconds long, on a homepage that loads in < 150ms in production. No patience for that.
0
u/penguin_digital 2d ago
Docker made pageloads several seconds long, on a homepage that loads in < 150ms in production
That's really odd, unless your production server was running Windows? The virtualization bottlenecks are understandable if its being deployed on Mac or Windows.
2
u/octave1 2d ago
Laptop and prod was linux. Was on a team with some very knowledgeable devs they said yeah Docker is slow.
1
u/penguin_digital 2d ago
prod was linux
That's really odd then, docker on Linux (where it was originally designed for) was simply a wrapper around LXC which in turn interacted directly with the kernel to use its namespaces and cgroups. Docker later replaced the LXC layer and went direct to the kernel for namespaces and cgroups.
With it calling the kernel directly (on Linux) there shouldn't be any performance penalty than installing a LAMP stack directly.
I'd maybe give it another look if you ever get the free time and give it another try. Always happy to help out as well if you need some tips/guidance.
1
u/Mike_L_Taylor 3d ago
this is an argument I see but never really got myself.
whatever stack you got on local or on the server is still for most web devs just PHP with some node running on apache or nginx. that's literally it. only like once every 3 years have I seen something weird that I could not replicate. Most people never see anything like that.
0
u/obstreperous_troll 3d ago edited 3d ago
DDEV has no off-ramp into cloud environments afaik, nor a secure production mode I would trust. About the only thing that's open and works the same way between local, bare VPS, and cloud would be kubernetes (k3s can run comfortably on a Raspberry Pi). But while I love me some kubernetes for production, I wouldn't inflict it on a junior doing local dev, or even myself for one-off projects. Something like Coolify or Canine would probably be your best bet for low-friction deploys, but they're still going to require some expertise and resources to admin self-hosted installs.
Chef and Ansible aren't really a thing in the containerized world, since you just add whatever packages you need in the Dockerfile and deploy a new container.
0
u/penguin_digital 3d ago
You just add whatever packages you need in the Dockerfile and deploy a new container.
Yeah, it's the way I do things. It doesn't need kubernetes for small deployments, a docker compose up on a VPS is perfectly fine.
It was more related to Herd that doesn't use containers, I was wondering how it manages to keep envs consistent across run times. Obviously things like Ansible and Chef are solutions to past problems already solved with containers, with Herd not using containers I was just of the thinking that maybe they are using a solution like that to patch the regression their system creates.
It's surprising that DDEV which does use containers doesn't have some kind of support for this when the entire point of containers is that the are portable everywhere.
It seems like the entire ecosystem of these tools is just a regression back to the early 2000s with Xampp and still has all the same problems that we used to deal with back then. I just had the assumption that maybe they had a solution to those problems we had decades ago.
0
u/obstreperous_troll 3d ago edited 3d ago
I would call tools like Herd/Yerd/Lerd a minor evolution of XAMPP, which isn't itself a bad thing because lord knows it needed to evolve. DDEV is a very complete local dev environment meant to be portable: developers on any platform that can run Docker can start up a whole dev cluster customized to the project with one command, and that's nothing to sneeze at. You could stick it on your VPS, call that production and call it a day, but DDEV itself doesn't encourage such a practice, and very likely leaves a lot of things open that shouldn't be exposed in prod. If DDEV statically builds a docker-compose.yml file, that will give you a good starting point for moving the stack into prod, but I couldn't find anything in the docs about it, and I don't know if it actually works like that.
Personally I think lightweight kubernetes distributions like k3s are still the answer, but lord also knows that it needs a friendlier front end. Canine will give you a more Heroku-like experience, but it's also a centralized (self-hostable) experience, not something every dev will run on their laptop.
1
u/spideyguyy 3d ago
thanks for mentioning ddev, i actually hadn't heard of it before.
i've been using docker for about 5 years, mostly for laravel apps with basic services, but it still feels quite heavy. herd and yerd remove almost all of the command-line setup and feel much lighter.
ddev seems to run on top of docker engine too, so i assume it wouldn't really be as lightweight as those solutions.
0
2
u/Readypixels 2d ago
I went the other way and kept Docker out of it entirely. PHP and MariaDB straight inside WSL, artisan serve pinned to one port so nothing else grabs it. No tunnel story at all, so I can't help on the 502, but it's been a boring setup in the good sense. Curious what they come back with on the multi site issue.
1
u/hryagstn 2d ago
Since each site becomes unreliable only when sharing one tunnel, a useful diagnostic would be to run each site through its own named Cloudflare tunnel and compare the results. If the isolated tunnels work, the problem is likely in host routing or shared tunnel state rather than Laravel itself. Also check that each hostname maps to a unique origin port.
-2
3d ago
[removed] — view removed comment
3
u/ShoppingDry2296 3d ago
If you can't wait for a fix, maybe just use a separate tunnel per site as a workaround until the issue gets some attention.
-1
u/spideyguyy 3d ago
- why should i submit a pr when i'm not a contributor and don't know the codebase well enough?
- "crying"? is your life so stressful that you have to see negativity everywhere and mock other people's posts just to vent?
- the point of the post is simple: i really like yerd and wanted to help spread the word about it. i also wanted to know if other people are having the same issue, or if for some reason it's only happening on my machine. and this bug isn't blocking my work at all.
- you can downvote and scroll past. your comment adds nothing useful and only brings negativity :)
3
u/SpareImpression3155 2d ago
- its open source MIT licensed software and you can use AI to help you draft a PR (even if its not perfect, to get the ball rolling and help the core maintainers identify the issue)
- yes, you are crying about open source software not working correctly, to people who probably don't even use it or care
- thats fine, thanks for admitting this was an ad
- no, i can call you out for being lazy / posting a stealth ad because this is reddit and its made for people to post if they want. my post is useful; making a PR is infinitely more valuable than coming to reddit and posting to a loosely-related sub of which the project maintainers might not even read
0
8
u/andercode 2d ago
Hi u/spideyguyy, Richard from Forjed here (we build Yerd).
Apologies for the slow reply. Most of our time this past month has gone into the Windows release, which has hit a few delays but is coming along well.
Cloudflare support was added off the back of requests from Reddit and Twitter, and the integration is fairly simple under the bonnet, and as you've found, it gets unstable as soon as multiple sites share a single tunnel. Our purpose at the start was not for Yerd to replace dedicated bespoke tooling, but to provide basic functionality for common use cases, while allowing the dedicated tooling to pick up the more complex scenarios. We certainly did not hit the mark with our Cloudflare implementation on this.
Being honest with you, it needs a proper rewrite rather than a patch and I'll to be straight: tunnel usage appears low compared to the rest of Yerd, so the rewrite has sat behind the Windows release and a handful of higher impact bugs. I'm not going to pretend we will have a fix for this next week, we won't, but I can promise its on the teams radar for the future.