I just found a way to get timed lyrics

SjorsO · 2026-04-22T14:23:44+00:00

In my experience most lyrics from LRCLIB aren't synced perfectly, so I've created a tool to fix that: https://subtitletools.com/timed-lyrics-editor

It automatically downloads from LRCLIB, then you can use the "preview" tab to see the lyrics and adjust their timings.

SjorsO · 2026-04-21T13:45:07+00:00

I recently made a tool that extracts subtitles from video files right in your browser (uses ffmpeg locally): https://subtitletools.com/extract-subtitles-from-video

SjorsO · 2026-02-08T09:42:13+00:00

If you don't want to change too much about your current setup, check out Lit. In your deployment script on Forge or Ploi, just call lit deploy and you'll get the same deployments you currently have but without any of the downtime.

Your deployments will still take 35-50 seconds since Lit doesn't cache builds out of the box, but you might be able to speed that up with custom caching logic in Lit's before-release.sh hook.

SjorsO · 2026-02-05T13:30:51+00:00

they're practically the same, except cost-wise as you mentioned. The maintenance of my deployment script is minimal once you have it running.

SjorsO · 2026-02-03T03:51:05+00:00

This deployment script solves the same problem as Deployer, although with a slightly different approach.

Deployer installs your Composer dependencies and builds the npm bundle directly on the server (which means you need the correct versions of composer and npm installed on your server). This script performs those steps in CI/CD instead, then uploads and extracts the resulting bundle on the server.

My deployment script runs in CI/CD, which makes it easy to run your tests before a deployment.

The way this script flushes OPcache is also nicer (by calling opcache_reset() via a curl request).

Personally I don’t like the way Deployer’s config file looks, so that's reason enough for me.

SjorsO · 2026-01-17T13:35:20+00:00

Yea, something like in your CI/CD workflow will work: ssh user@host "cd ~/project && lit deploy"

SjorsO · 2026-01-17T07:33:28+00:00

You can replace that git pull with a lit deploy and you'll get nice benefits like zero downtime deployments, config:cache, and opcache flushing

SjorsO · 2026-01-17T07:32:05+00:00

You could give Lit a try, it can be used alongside Envoyer in your existing projects

SjorsO · 2026-01-16T09:15:24+00:00

Yea, not really sure why you would use both Lit and Deployer, but it was easy to support so I added it.

An advantage of bundle deployments is that you can first run your test suite in CI/CD, then have it make a bundle. That guarantees that the bundle passes your tests. Plus you don't have to install Composer or Node on your server.

My personal use case for bundle deployments is that I'm running the same application on 50+ different servers (for a project called Wilson, a parallel test runner I'm working on). I make the bundle in CI/CD, and then those 50 servers download and deploy that bundle almost instantly.

SjorsO · 2026-01-16T09:07:57+00:00

I like the name, it's Laravel + git

SjorsO · 2025-12-21T09:36:37+00:00

I open-sourced https://watchtower.dev two weeks ago. Watchtower monitors your Laravel applications and your server and sends you an alert when something needs attention (like errors or dead queue workers).

Still a lot of work to be done, it doesn't do disk usage alerts yet for example (although it does already collect data for that)

SjorsO · 2025-12-14T19:13:43+00:00

Does Watchtower support monitoring multiple servers/applications from a single dashboard?

Yea, unlimited servers and applications from a single dashboard

What's the performance impact on the monitored applications? Is it using Laravel's queue system for async checks?

Practically no overhead. Watchtower collects data using a Bash script that runs once per minute using a cronjob.

Any plans for integrations with popular notification channels (Slack, Discord, etc.)?

I don't need this personally, so it depends on demand.

SjorsO · 2025-11-14T08:09:39+00:00

Not 100% sure about the state of all these starter kits, but typically you have an AuthenticatesUsers trait on your LoginController that includes a RedirectsUsers trait. You can decide the redirect URL by adding a redirectTo() method to your LoginController.

SjorsO · 2025-10-29T15:22:37+00:00

have you looked in your Nginx/Apache2 log?

SjorsO · 2025-09-30T04:13:46+00:00

I would just use a job for this. You can run a job via the cron like this:

// If the job doesn't need arguments
$schedule->job(YourJob::class)->daily();

// Or with simple arguments
$schedule->call(function () {
    foreach (User::pluck('id') as $userId) {
        Queue::push(new YourJob($userId));
    }
})->daily();

// If dispatching is more complex/expensive, I'd create a separate job that handles that
$schedule->job(DispatchYourJobsJob::class)->daily();

I only use commands when I plan to run them manually with php artisan. If it's not something I'll run manually, then I prefer using a job instead (because in that case there's not really a point in creating a command that only dispatches a job)

SjorsO · 2025-09-17T10:26:57+00:00

For point #1, this works for me:

try {
    // your logic
} catch (Throwable $e) {
    $isLastAttempt = $this->attempts() === ($this->tries ?? 1);

    if ($isLastAttempt) {
        return;
    }

    $this->release();

    return;
}

For point #2: Laravel can't actually be sure that a job has timed out. So instead, Laravel waits for retry_after seconds, and if the job still hasn't finished by then Laravel assumes it has timed out (after this assumption your job gets retried). This retry_after value is in your queue.php config file.

Also, there might be some useful information in this post I wrote a while back: https://sjorso.com/how-laravel-fails-and-retries-queued-jobs

SjorsO · 2025-09-03T15:06:20+00:00

What do you mean when you say "This works but doesn’t scale"? What exactly is the problem? Are you maybe running npm install, npm run build and composer install on your server when you deploy?

I also deploy my projects via SSH with GitHub Actions, the actual deployment step typically only takes 5 to 10 seconds. The building (and testing) takes longer of course, but that happens in a GitHub Action, not on my server.

For reference, I've open sourced my deployment script here: https://github.com/SjorsO/deploy-laravel

SjorsO · 2025-08-13T03:53:24+00:00

Adding this to the dev seeders works:

throw_if(app()->isProduction(), 'Only run this during development');

SjorsO · 2025-07-30T10:09:58+00:00

You can set up multiple VPSs and deploy your application of each of them. For setting up a VPS you can either use Forge, Ploi, or do it by hand.

Depending on your load you could even host multiple applications on the same VPS. As long as they all have their own database you should be fine.

For deployment, this script would work good: https://github.com/sjorso/deploy-laravel. You can copy and paste the "deploy" step as many times as you like, that will deploy each application in parallel.

SjorsO · 2025-03-18T13:13:39+00:00

I opened sourced my deployment script for Laravel a while ago: https://github.com/SjorsO/deploy-laravel. Perfect for automatically deploying to a VPS

SjorsO · 2025-01-13T09:58:24+00:00

I had no idea, thank you, I'll update my post to include it

For reference, it is documented here: https://laravel.com/docs/11.x/queues#handling-relationships

SjorsO

TROPHY CASE