https://laravel.io/index.php/forum/feed The RSS feed for the Laravel.io forum contains a list of all threads posted by community members. 2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30876

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30875

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30874

ip() and broken HTTPS detection. Queue workers and Supervisor This is the part people skip and regret. A basic Supervisor config for a Laravel queue worker: [program:laravel-worker] process_name=%(program_name)s_%(process_num)02d command=php /var/www/your-app/artisan queue:work --sleep=3 --tries=3 --max-time=3600 autostart=true autorestart=true stopasgroup=true killasgroup=true user=www-data numprocs=2 redirect_stderr=true stdout_logfile=/var/www/your-app/storage/logs/worker.log stopwaitsecs=3600 Set numprocs based on actual CPU/RAM available on the plan you're on, not on what you'd use on a big managed cluster. Oversubscribing workers on a modest VPS is a common cause of memory exhaustion crashes. SSL and zero-downtime deploys Use Let's Encrypt via Certbot for SSL. Most VPS providers, offshore ones included, allow standard port 80/443 access for the HTTP-01 challenge, but confirm this before relying on it, since some privacy-focused networks restrict inbound ports by default for abuse prevention. For zero-downtime deploys without Envoyer, a symlink-based release strategy (releases/ + shared symlink to current) works well and is provider-agnostic. Deployer (php.deployer.org) is a solid lightweight option if you want this scripted. Data locality and latency considerations If your users are concentrated in Europe, picking a VPS in an EU data center measurably improves TTFB versus a US-based one, independent of any privacy/jurisdiction reasoning. I tested this on a project hosted with **QloudHost**, which runs a Tier III data center in Amsterdam, and the latency difference for EU-based users versus a US East Coast VPS was noticeable in real user monitoring, not just synthetic pings. Worth factoring in even if jurisdiction isn't your primary concern. Security hardening basics that get skipped Disable root SSH login, use key-based auth only ufw or provider firewall rules limited to 22 (restricted IP if possible), 80, 443 Fail2ban for repeated auth failures Keep APP_KEY out of version control, obviously, but also confirm it's actually set on the server after clone, since a missing key silently breaks encrypted sessions and cookies Rotate .env file permissions to 640 at minimum Questions for the community A few things I'm still figuring out and would genuinely like input on: For those running Laravel on non-mainstream VPS providers, what's your queue worker monitoring setup? I'm using a simple queue:monitor + healthchecks.io ping right now, but curious what others do beyond Horizon (which needs Redis and more resources than some smaller VPS plans comfortably offer). Anyone dealt with TrustProxies misconfiguration specifically on offshore providers with their own edge/CDN layer? Curious what patterns you've landed on. Happy to share more of the deployment script if useful.]]>

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30873

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30872

[ 'token' => env('ACME_TOKEN'), ], ]; ``` Application code should then read it through Laravel's configuration repository: ```php $token = config('services.acme.token'); ``` I also test deployment builds with configuration cached. That catches the direct-access problem before production. ## Environment-file drift remains A related issue is keeping the key inventories of `.env`, `.env.testing`, `.env.production`, `.env.sample`, or renamed templates aligned without comparing or exposing their values. Some practical questions for teams maintaining several environments: - Do you treat every `.env.*` file as a complete contract, or are some of them partial Vite-style layers? - How do you detect a key used by application code but declared nowhere? - How do you handle keys consumed only by Docker, CI, a process manager, or hosting infrastructure without producing false positives? - Do commented assignments in non-active templates count as documented optional keys in your workflow? - Do you audit raw `getenv()`, `$_ENV`, `$_SERVER`, Vite, Blade, and PHPUnit usage as part of the same review? ## An optional development guard While working through these cases, I built the open-source [Laravel Env Guard](https://github.com/Codegenie-BE/laravel-env-guard): ```bash composer require --dev codegenie-be/laravel-env-guard ``` It runs during guarded Artisan boots in the local environment by default. It checks unsafe `env()` usage and environment-key drift, but reports keys only: no values, telemetry, network calls, automatic `.env` changes, or production scanning by default. The current release supports Laravel 12 and 13 across their valid PHP 8.2–8.5 combinations. Disclosure: I maintain this package through Codegenie. I am looking for technical feedback about real-world environment-file conventions and false-positive or false-negative cases, not stars. Please do not share real environment values or secrets.]]>

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30871

$user->id, 'processor_token' => $charge->id, // e.g. Stripe charge/payment intent ID 'amount' => $amount, 'status' => 'pending', ]); ``` **2. Enforce Idempotency on Every Write Endpoint** Network retries, double-taps on the frontend, and queue redelivery can all cause the same charge or transfer request to hit your API twice. Require an Idempotency-Key header and store a hash of processed keys so a repeated request returns the original result instead of creating a duplicate transaction. ``` php if (Cache::has("idempotency:{$key}")) { return Cache::get("idempotency:{$key}"); } ``` Laravel doesn't do this for you out of the box, so it's worth building as reusable middleware if you're handling any kind of money movement. **3. Use Database Transactions + Locking for Balance Updates** Never do a read-then-write balance update without locking the row. Race conditions here are exactly how double-spends happen. ``` php DB::transaction(function () use ($walletId, $amount) { $wallet = Wallet::where('id', $walletId)->lockForUpdate()->first(); if ($wallet->balance < $amount) { throw new InsufficientFundsException(); } $wallet->decrement('balance', $amount); }); ``` **4. Rate Limit Aggressively on Financial Endpoints** Laravel's built-in throttle middleware is a good start, but for payment endpoints specifically, consider tighter limits and per-user (not just per-IP) throttling to blunt card-testing and enumeration attacks. ``` php Route::middleware('throttle:10,1')->group(function () { Route::post('/payments/charge', [PaymentController::class, 'charge']); }); ``` **5. Verify Webhooks Cryptographically** If you're consuming webhooks from a payment processor, always verify the signature before trusting the payload. Don't just check that the request "looks right." ``` php $sig = $request->header('Stripe-Signature'); $event = \Stripe\Webhook::constructEvent($payload, $sig, config('services.stripe.webhook_secret')); ``` **6. Log Everything, But Never Log Sensitive Data** Full audit trails matter a lot for financial systems — who initiated a transaction, when, from where. Just make sure your logging channel scrubs card numbers, tokens, and auth headers before anything hits disk. **7. Use Policies/Gates for Every Financial Action** Don't rely on route middleware alone. Wrap every transfer, withdrawal, or balance-changing action in an explicit authorization check via Laravel's Policy classes, so it's obvious and testable that a user can only act on their own wallet/account. None of this is Laravel-specific in principle — it's standard fintech engineering discipline — but Laravel gives you solid primitives (transactions, middleware, policies, queues) to implement it cleanly if you use them deliberately rather than bolting security on after the fact. At Nimble AppGenie we've run into a lot of these issues while working on [fintech APIs](https://www.nimbleappgenie.com/blogs/5-useful-apis-for-your-next-project/) for wallet and payment products, and idempotency + row locking are consistently where teams get bitten first. What are others doing for fraud detection or velocity checks at the API layer? That's the piece I'm still refining.]]>

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30856

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30870

'example keyword', ]); $data = $response->json(); This approach keeps the SERP retrieval logic separate from the rest of the application and makes the returned data easier to store or analyze. For developers who need real-time Google SERP data, Serpstack provides structured JSON or CSV responses and supports parameters such as location, language, and device type. )If you're exploring this approach, you can learn more about Serpstack here: https://apilayer.com/products/serpstack/]]>

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30869

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30868

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30867

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30866

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30865

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30864

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30863

workflow('summary') ->rawPrompt('Summarize the latest customer feedback.') ->build(); $run = $rick->run($workflow); echo $run->output(); Installation: composer require rickphp/laravel-rick:^0.1 php artisan migrate ## What it currently supports - synchronous and queued workflow execution; - Laravel AI provider calls; - parallel operations with deterministic result ordering; - manual review, candidate selection and external input; - encrypted, tenant-scoped persistence; - pricing and resource budgets; - run metrics, snapshots and timelines; - transactional outbox delivery; - recovery of interrupted runs; - protection against blindly repeating ambiguous paid requests. One of the included examples generates five independent implementation plans, persists all five candidates, pauses the workflow for human review and continues only after the application selects a candidate. Another example dispatches independent operations through Laravel queues. Results are reduced in declaration order even if workers complete them in a different order. Duplicate delivery of an already completed invocation does not trigger another provider call. Laravel Rick 0.1.0 supports PHP 8.3+ and Laravel 12–13. It is open source under the MIT license. This is the first public release, so the API may still evolve before 1.0. I would especially appreciate feedback on: 1. Is the workflow-building API understandable? 2. Which real Laravel AI workflow would you try to implement with it? 3. What is missing from the installation or use-case documentation? GitHub: https://github.com/para1992/laravel-rick Packagist: https://packagist.org/packages/rickphp/laravel-rick Release: https://github.com/para1992/laravel-rick/releases/tag/v0.1.0 Issues and feature requests: https://github.com/para1992/laravel-rick/issues/new/choose]]>

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30862

author->name; } ``` First line, one query, grabs every post. No issue there. But the second `$post->author` inside the loop? That fires a brand new query every single time. Loop through a hundred posts and you've just run a hundred and one queries. Loop through ten thousand (and I have, on a job board client, don't ask) and you've basically DDoS'd your own database. What makes this one so annoying to catch is that the code reads fine. It's not a typo, it's not a broken relationship, it just... doesn't scale. Works great with seed data, falls over the second real traffic shows up. Which, of course, is usually a Monday morning, in production, right when everyone's trying to log in. **How I actually catch these now** Debugbar's the obvious tool, sure, everyone's got it installed. But honestly I stopped trusting it as my only check a while back because it misses anything that isn't a normal HTTP request, queue jobs, artisan commands, that kind of thing never show up in it. These days I just drop a listener into a service provider and dump straight to the log: ```php DB::listen(function ($query) { Log::info($query->sql, $query->bindings); }); ``` Hit the page once, then go read the log. If you spot the same query shape over and over with just the bound ID changing, congrats, you found it. It's usually pretty obvious once you're looking for it. **The actual fix (it's genuinely this easy)** Eager loading. That's the whole trick. You tell Eloquent up front what you'll need, it grabs everything in one extra batched query instead of firing off N of them. ```php $posts = Post::with('author')->get(); foreach ($posts as $post) { echo $post->author->name; } ``` Two queries. Total. Doesn't matter if there's a hundred posts or a hundred thousand. `with()` runs a single `WHERE IN` after the posts come back, then stitches everything together in memory before your loop ever runs. Same exact output as before, wildly different performance. Nested relationships stack with dot notation: ```php $posts = Post::with('author.company')->get(); ``` And you can trim columns on the eager load too if you're being careful about payload size: ```php $posts = Post::with('author:id,name')->get(); ``` One gotcha there, and it got me once, if you forget to include the foreign key (`id` in this case) the relationship just silently doesn't resolve. No error, just null authors everywhere and a confused ten minutes figuring out why. **Where eager loading still doesn't save you** Two spots I keep running into. First, conditional eager loading in API resources, where `whenLoaded()` looks perfectly safe but somebody forgot to actually call `with()` in the controller. Laravel won't complain, it'll just fall back to querying per row and nobody notices until the response times creep up. Second one's sneakier, computed accessors. If your model's got something like `getFullNameAttribute()` reaching into `$this->company->name` internally, that accessor will trip N+1 the moment you loop over a collection and call it, even if everything else is eager-loaded correctly. Saw this exact thing on a project a team at Hidden Brains had built, all the controller-level eager loading was solid, but a Blade component was calling an accessor that reached into an unloaded relation. Took a while to track down because the controller looked completely clean. **One habit that's actually saved me a few times** Turn on strict mode locally. `Model::preventLazyLoading()` in `AppServiceProvider::boot()`, gated behind an environment check so it doesn't blow up production: ```php Model::preventLazyLoading(! app()->isProduction()); ``` Throws an exception the second lazy loading happens instead of just quietly running the extra query. Turns a silent problem into a loud one, in dev, where you actually want it to be loud. Small thing, but it's caught this bug for me more than once before it ever shipped. Anyone got a nastier N+1 case than the accessor one? That's the one that always ends up hiding somewhere I wasn't looking.]]>

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30861

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30851

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30860

2026-08-23T11:24:48+00:00 https://laravel.io/index.php/30859

2026-08-23T11:24:48+00:00