DEV Community: Daniel, Petrica Andrei-Daniel

Security Advisories, a Sync Gap, and Health Badges for Your README

Daniel, Petrica Andrei-Daniel — Mon, 29 Jun 2026 16:35:27 +0000

I shipped a new feature on LaraPlugins.io this week: security advisories for Laravel packages. They check plugin versions against known vulnerabilities.

The very first thing they did? Surface a bug I had missed for two months.

What broke

A while back, I restructured the data sync pipeline. I disabled the old Packagist version sync commands and noted them in the code as "replaced." The replacement command, app:plugin:health-sync-all, did sync health scores. But it did not sync plugin versions.

Health scores, search, and everything else kept updating. So there was nothing visibly wrong. It was only when the new security advisory feature started cross-referencing version data that the stale state surfaced.

When advisories first launched, they compared plugin versions against our local data, which was stale. This is what tipped me off. Some plugins were showing lower Health scores than they should because the version information was behind.

What was fixed

I re-enabled the daily version sync (top 5,000 packages) and the weekly full sync (all packages). The two-month backlog was significant. I switched from loading all records into memory to using cursor-based iteration with chunk(), which cut peak memory usage substantially and lets the backlog process safely.

Version sync is now also explicitly part of the weekly health pipeline too.

For security advisories specifically, I added a fallback to the live Packagist API. Even if local version data is temporarily behind, advisory checks use the latest version info from Packagist directly. This means advisory badges stay accurate regardless of sync state. The gap was discovered because of the feature. The feature is now resilient to it.

While I was in the pipeline anyway

I also improved something I hope maintainers will find usefull: health badges for your README. They show your plugin's health score and security status at a glance.

[![LaraPlugins](https://laraplugins.io/badges/plugin/vendor/package.svg)](https://laraplugins.io/plugins/vendor/package)

Replace vendor/package with your Packagist package name or just use the get embed button on the plugin page on laraplugins.

The badge updates automatically with the new data on the site.

Here is an example of the generated badges using spatie/laravel-medialibrary as an example. The Plugin fact checks is my favorite.

If you use LaraPlugins to evaluate packages

Your data is current now. Security advisory scores are backed by live version data. You can also pull advisories directly in your editor via the LaraPlugins MCP server without visiting the site.

Timeline

The fix is deployed. The backlog of version data will take 4 to 8 hours to fully catch up. Everything should be current within the day.

Transparency is part of building in public. Sharing what went wrong, what I fixed, and what I learned, that is the whole point i think.

Thank you for reading my article

I am working hard to build a health directory for laravel and any help is appreciated. If you want to help please subscribe to my blog.

                <span>Subscribe</span>
                <span><svg xmlns="http://www.w3.org/2000/svg" height="24" width="24" viewBox="0 0 24 24">
    <g stroke-linecap="round" stroke-width="2" fill="currentColor" stroke="none" stroke-linejoin="round">
        <g>
            <circle cx="4" cy="12" r="3"></circle>
            <circle cx="12" cy="12" r="3"></circle>
            <circle cx="20" cy="12" r="3"></circle>
        </g>

    </g>
</svg></span>



            Email sent! Check your inbox to complete your signup.

No spam. Unsubscribe anytime.

My LaraPlugins Performance Audit: 12 Fixes That Saved my Stressed server

Daniel, Petrica Andrei-Daniel — Mon, 22 Jun 2026 16:53:25 +0000

My 8 GB Hetzner VPS was sitting at 90%+ memory usage, all day, every day. New Relic alerts were pinging me constantly. The noise was so bad I started tuning them out, which is exactly when real problems slip through.

LaraPlugins.io indexes over 76,000 Laravel packages. It runs health checks, syncs GitHub data, ingests Packagist versions, and serves a public directory. Behind the scenes, Horizon workers chew through jobs 24/7. A few weeks ago, the server was barely keeping up.

I spent a week digging into the bottlenecks. Here are the 12 fixes that made a real difference, with the actual numbers.

The Starting Point

Twelve Horizon supervisors, each with unlimited job processing. Workers grabbing 500 MB each. A monolithic maintenance supervisor that ran for two hours at a time. And during the weekly plugin health recalculation, a single job type was triggering 50,000 Cloudflare cache purge jobs in one cycle.

The server had 8 GB of RAM. It was not enough.

Fix 1: Split the Maintenance Monolith

The maintenance supervisor was one worker processing everything: GitHub syncs, health calculations, analytics, and background tasks. It ran with a 7,200-second timeout. If anything stalled, everything stalled.

I split it into dedicated supervisors: github-sync (2 workers, 300s timeout, 400 MB) and health (2 workers, 600s timeout, 500 MB). Each does one thing. If GitHub's API rate-limits the sync worker, the health worker keeps running.

The old analytics supervisor became background, merged with low-priority tasks, and dropped from 250 MB to 128 MB. Generic names like "low" and "analytics" became names that describe what the queue actually does. Makes debugging faster when something breaks at 3 AM.

Fix 2: Memory Caps Everywhere

Every Horizon worker had maxJobs: 0, meaning unlimited. A worker could process jobs forever, slowly leaking memory until the OOM killer stepped in.

I set maxJobs: 100 across all supervisors. After 100 jobs, the worker restarts. Memory gets released back to the OS. The defaults also dropped: 500 MB became 256 MB on the default queue, 384 MB on packagist-high, and 128 MB on background. Combined, the memory ceiling dropped by roughly 2 GB across all workers.

The failed job retention window went from 10,080 minutes (7 days) to 7,080 (5 days). Horizon's queue trim snapshot interval jumped from 12 to 2,016 minutes. These are small config changes that add up to less Redis memory churn.

Fix 3: The 50,000-Job Problem

Every time a plugin's data was updated, a job dispatched to purge its Cloudflare cache. During the weekly health recalculation, with all 56,000 plugins being refreshed, over 50,000 InvalidatePluginCloudflareCache jobs hit the queue.

That is 50,000 individual Redis pushes, 50,000 worker pickups, 50,000 Cloudflare API calls spaced across the queue. The queue backed up. Workers spent cycles dispatching and picking up purge jobs instead of doing actual health calculations.

The fix: a Redis SADD collects purged paths into a set. A single FlushPendingCloudflarePurgesJob pops 30 URLs at a time, sends them to Cloudflare's bulk purge endpoint, and self-reschedules if more remain. Max 10 batches per cycle, or 300 URLs per flush. Instead of 50,000 jobs, it is one job calling itself. The Redis set acts as a natural deduplicator as well: if the same plugin path is marked for purge twice, SADD only stores it once.

Fix 4: The Column Nobody Reads

The plugins table has a packagist_metadata column. It is a JSON blob containing every version's metadata: requirements, dependencies, descriptions. It is large. And it was loaded on every single query to the Plugin model, even though sync jobs never read it. They only write it.

I added a WithoutPackagistMetadataScope global scope to the Plugin model. Every query now excludes that column by default. Jobs that need the metadata load it explicitly with withoutGlobalScope(). The query payload for list operations dropped significantly. MySQL spent less time shuffling JSON blobs across the wire.

Fix 5: Indexes That Should Have Been There

Three missing indexes: plugin_versions support version columns (used in every compatibility check), failed_jobs.queue (Horizon's dashboard queries it constantly), and the vendor detail page query path. These were not exotic compound indexes. They were obvious single-column indexes that I simply had not added when the tables were created.

The vendor detail page also got a column selection pass: instead of SELECT *, it now selects only the columns it actually renders. Small change, but the page went from noticeably slow to instant.

Fix 6: Cache Longer

Aggregate queries (plugin counts by tag, health score distributions, PHP version stats) were cached for too short a window. I bumped the TTLs to 6 hours and 24 hours depending on the query. These numbers do not change between deploys. There is no reason to recalculate them every 30 minutes.

Fix 7: Queue MCP analytics Off the Critical Path

LaraPlugins exposes an MCP server for the plugin search tool. Every request was logging anonymized analytics events synchronously before returning a response. A event write meant a slow MCP response. Moved the logging to a queued job on the background queue. MCP responses stayed fast regardless of log throughput.

Fix 8: Health Checks That Checked Nothing

Several health check jobs were running at frequencies that did not match the data freshness they protected. Some were redundant checks that another job already performed. Trimmed the schedule to match actual refresh needs and removed the duplicates.

Fix 9: MySQL Tuning

Increased the sort_buffer_size in the Docker Compose MySQL config. LaraPlugins runs sorting-heavy queries on plugin lists (by downloads, by stars, by health score). The default sort buffer was too small for the dataset size, causing disk-based sorts that slowed down listing pages.

Fix 10: Horizon Retention Trimming

Horizon stores job history in Redis. The completed job retention was at 60 minutes, the queue trim snapshot interval at 12 minutes. These are fine for a small app. For LaraPlugins, with thousands of jobs per hour, Redis memory was bleeding into job history storage. Bumped the queue trim to 2,016 minutes and reduced failed job retention to 5 days. Redis memory stabilized.

Fix 11: Rate Limit Recovery

GitHub's API rate-limits aggressively. When the sync worker hit the limit, it would crash and Horizon would retry it, sometimes before the rate limit window reset. Added explicit rate limit detection with proper backoff: when GitHub returns a 429 or a retry-after header, the job releases itself back to the queue with a delay matching the reset window. No more spinning wheels against a rate limit wall.

Fix 12: Nightwatch Silencing

Laravel Nightwatch was ingesting every queue job, every request, every log into its agent. For a job-heavy app like LaraPlugins, that meant an enormous volume of observability data, most of it noise. Reduced the event ingestion to only what I actually look at. The agent container stopped being a resource drain.

The Results

The 8 GB VPS dropped from 90%+ memory usage with constant alerts to a stable 65 to 80% range. New Relic went quiet. Response times stayed flat at under 100 ms average. No regressions.

The Horizon queue shrank from 12 supervisors doing vague things to 9 supervisors doing specific things. Memory leaks from unlimited job processing stopped. The 50,000-job Cloudflare purge spike became a single self-rescheduling job.

And I can sleep without my phone buzzing about a server that is "probably fine."

What I Would Do Differently

Most of these fixes were not clever. They were cleanup. Indexes I forgot to add. A column nobody read being loaded on every query. A cache TTL that was too short for no good reason. Queue names that made debugging harder.

If I were starting LaraPlugins again, I would add maxJobs to every Horizon supervisor from day one. I would default to global scopes for large JSON columns on read-heavy tables. And I would batch external API calls by default instead of dispatching one job per call. These are not architecture decisions. They are habits.

The biggest lesson: when your monitoring goes noisy, you have exactly two choices. Fix the root cause, or tune the alerts. Every day you tune the alerts without fixing the cause, you are training yourself to ignore your own dashboard.

How to Replace Raw S3 URLs with a Laravel Image Proxy (and Keep Your CDN Cache)

Daniel, Petrica Andrei-Daniel — Mon, 15 Jun 2026 15:52:36 +0000

If you're serving images and media files directly from an S3-compatible object storage (like Hetzner Object Storage, AWS S3, or DigitalOcean Spaces), you're probably used to URLs that look like this:

https://storage.example.com/my-bucket/project/files/posts/hello-world/cover.png

That's ugly. It exposes your storage provider and bucket name. And if your bucket is private, you can't even serve those URLs directly. You'd need signed URLs or a proxy.

Here's how I replaced all raw S3 media URLs on my Laravel blog with clean proxied paths through the application, while keeping 24-hour CDN caching for performance.

The architecture

We run a typical Laravel + Octane stack behind Traefik with Cloudflare. All media is stored on an S3-compatible object storage in two buckets: a private one for uploaded media (project/files) and a public one for auto-generated Open Graph images (project/og-images).

Originally, the app generated URLs directly to object storage using Storage::url(). This meant:

Private bucket URLs were inaccessible (and switching to public was not an option)
Provider details were exposed in every page's HTML
No control over caching at the application level

Step 1: Build a URL helper

First, I created a MediaUrlBusiness class that centralizes URL generation for both disks. Instead of calling Storage::disk('og-images')->url($path) or Storage::url($path) in blade templates, I now call:

MediaUrlBusiness::forOgImage($path); // → /storage/og-images/posts/slug.png
MediaUrlBusiness::forMedia($path); // → /storage/media/posts/slug/cover.png

This returns a clean relative path like /storage/og-images/.... All 6+ blade templates that previously generated raw S3 URLs now use this single helper.

Step 2: The proxy controller

The ObjectProxyController catches all /storage/{disk}/{path} requests. It:

Validates the disk is one of the allowed ones (media → private bucket, og-images → public bucket)
Resolves the full S3 key using the disk's configured prefix
Streams the file from object storage using response()->stream() with proper Content-Type and Content-Length headers
Sets a Cache-Control: public, max-age=86400 header so Cloudflare and browsers cache aggressively

Here's the core of it:

$disk = Storage::disk($diskMap[$diskSegment]);
$stream = $disk->readStream($fullPath);

return response()->stream(
    callback: function () use ($stream) {
        fpassthru($stream);
        fclose($stream);
    },
    headers: [
        'Content-Type' => $disk->mimeType($fullPath),
        'Content-Length' => $disk->fileSize($fullPath),
        'Cache-Control' => 'public, max-age=86400, immutable',
    ]
);

A detail that tripped me up: Storage::download() and streamDownload() buffer the entire file into memory. For large images, that wastes memory. Switching to readStream() + response()->stream() sends the file directly from S3 to the client without buffering.

Note: Laravel's S3 driver supports fileSize(). For custom disks, use $disk->size() instead.

Important: anything in the private bucket is now accessible through the proxy if someone guesses the path. Make sure that bucket only holds public-facing assets.

Step 3: Route and middleware setup

The proxy route lives in routes/static.php alongside other cacheable frontend routes:

Route::get(uri: '/storage/{disk}/{path}', action: ObjectProxyController::class)
    ->where('path', '.*')
    ->name('storage.proxy');

I also modified the SetCacheControlHeader middleware to skip responses that already have a Cache-Control header set (since the proxy controller sets its own). This way the middleware doesn't override our carefully tuned 24-hour cache policy.

Step 4: Wire it up everywhere

The MediaUrlBusiness helper is now used in:

Post, page, and tag show views, for both OG images and feature images
Homepage and archive listings, for post card images
Case study components, for service images
OgImageBusiness, for storing and retrieving generated OG images

Every call to Storage::disk('og-images')->url(...) or Storage::url(...) was replaced with the appropriate MediaUrlBusiness::for*() method.

What about the admin panel?

The Filament admin panel has its own media proxy. The existing MediaProxyController handles CORS issues when editors browse and insert images in the RichEditor. That stays as-is; it's authenticated and not meant for public caching.

The result

Before:

<img src="https://storage.example.com/my-bucket/project/files/posts/hello-world/cover.png">

After:

<img src="/storage/media/posts/hello-world/cover.png">

Clean, provider-agnostic, and cache-friendly. The URL no longer leaks my storage provider or bucket name. And if I ever switch providers, I only need to change the disk configuration. The public URLs stay the same.

Need this for your site? If your team doesn't have the bandwidth to implement this, I can set it up for you: clean proxied image URLs, CDN caching, and private bucket security. Get in touch →

50,000 Spam Emails and a 3 AM Panic: What Happened When I Forgot About a Side Project

Daniel, Petrica Andrei-Daniel — Mon, 25 May 2026 14:28:57 +0000

The short version: Someone exploited an outdated Livewire version on a dormant side project of mine. They stole my .env file, used the Mailcoach API keys to send 50,000 spam emails, and I spent a panicked night tearing through every project I own trying to find the source.

Here is the full story, what I learned, and why Docker saved me from a much worse outcome.

It was Wednesday, May 20. I was in class when my phone buzzed with an email from Mailcoach:

Your submissions have been blocked due to a high bounce rate or spam reports.

I read it. Felt that cold drop in my stomach. And then I had to put my phone away and finish class.

There is a special kind of dread that comes from knowing something is wrong but not being able to look at it. I sat through the rest of my Japanese lesson with half my brain running through worst-case scenarios.

Around 18:00, I finally opened my laptop.

The moment of terror

I logged into Mailcoach and my heart stopped. Over 50,000 emails had been sent from my account. All of them spam. Phishing links. Going out under my name.

I had never experienced anything like this before. I was shocked. My immediate reaction was to delete every single API token in Mailcoach and my GitHub API tokens. Then I wrote to their support team asking for help figuring out how this happened.

The long night

I spent the next nine hours reviewing every project I own.

danielpetrica.com. laraplugins.io. adventcalendar.tech. And some other smaller, unused projects. Every small demo site, every experiment, every dormant project sitting on my server. I checked logs, checked file permissions, checked for anything unusual. Nothing.

To make things worse, that same day Symfony announced 19 CVEs across their projects. My brain went there immediately. Was it Symfony? Was one of my sites running an affected version? I went down that rabbit hole for a while.

Nothing.

At 3 AM, I had to make a call. I secured what I could, changed what I could, and went to sleep. I was frustrated. I was tired. And I still had no idea what happened.

Finding the source

The next day I kept digging. Project by project. And then I found it.

A small side project. One of those things you build, launch, and forget about. It was running an outdated version of Livewire with a public CVE. I had not updated it. That was my fault.

The attacker found it through automated scanning. These bots crawl the web looking for known vulnerabilities in exposed applications. They found Livewire, found the CVE, and were inside within hours. They uploaded a web admin script that let them read anything the Apache user had access to inside that Docker container.

Including my .env file. Which held my Mailcoach API keys.

The Docker blessing

Here is where things could have been much worse.

That side project was running inside a Docker container. The attacker had access to that container, but they could not escape it. They could not reach my other projects, my other databases, or the host system itself. The blast radius was limited to that one service.

I originally set up Docker Compose just as a convenience for myself. I never thought of it as a security measure in the beginning. But it ended up being the wall that stopped the attack from spreading.

The evidence I lost

This part still stings.

When I finally identified the compromised container, I did the natural thing. I took it down: docker compose down -v. Volumes included.

And just like that, the attacker's files were gone. The web shell, the logs of what they did, any clues about their entry point,all of it erased.

I realized my mistake later. I should have copied the container's storage before killing it. I should have preserved the evidence. But in the moment, my only thought was, "Shut it down now."

I spent the next few hours going through my reverse proxy logs instead. Those survived. They showed the attacker's pattern clearly. Automated scanners hit the site repeatedly. Once they confirmed the Livewire vulnerability, the actual compromise happened within hours. This was not a targeted attack on me. I was just another domain on a list.

What scared me most was how fast everything happened. The scan, the exploit, the credential harvest, the spam campaign. It felt automated end-to-end. If AI is making these attacks faster and more efficient, we are all going to need to be much more proactive about monitoring and maintenance. Myself included.

The silver lining

Mailcoach handled this better than I could have hoped.

They noticed the spam spike before I did. They suspended my submissions proactively. When I reached out, they worked with me to investigate. And when the dust settled, they dropped the charges for those 50,000+ emails from my invoice entirely.

That is the kind of provider behavior that builds loyalty for life.

Thank you to the Mailcoach team.

What I changed

Since this happened, I have made a few changes:

I set up automated dependency update alerts for every project, including the dormant ones. If a project has a composer.json, I get notified when its dependencies are outdated.
I conducted a review of all my side projects. Some got updated. Some got archived. Some got shut down entirely.
I reviewed my API token strategy. Tokens now have strict scopes and shorter lifespans where possible.
I am also looking into environment variable management strategies and exploring how to better align them with my Docker setup.
I accepted that I need better monitoring. A 15:52 alert that I cannot act on until 18:00 is useless if I do not have a plan for that gap.

The uncomfortable truth

This happened because I made a mistake. I had a public, dormant website with an outdated dependency. I knew better; I just did not prioritize it until I forgot about the site entirely.

But the takeaway is not just "be more careful." It is that our industry has a long tail of forgotten projects that are ticking time bombs. Every developer I know has side projects gathering dust on a server somewhere. Those are exactly what the scanners are looking for.

Go update your dependencies. Or shut down what you are not maintaining. Because the bots are not going to wait until you have time. I learned that the hard way.

Have fun building. And update your Livewire, please.

P.S. I was already convinced of this before, but now I am certain: Mailcoach is the best email tool for campaigns and transactional emails. Go check them out here (referral link).

The State of Laravel Packages 2026

Daniel, Petrica Andrei-Daniel — Sat, 31 Jan 2026 23:00:00 +0000

At the end of November, I shared a questionnaire to discover what the community thinks about the state of Laravel packages today. I wanted to focus on the real-world pain points developers face. To ensure I got busy developers to respond, I kept it short, under 3 minutes on average.

From this findings Laraplugins.io was born. Now it indexes more than 16000 plugins. Go find their health status now

Without an established audience, I managed to reach around 200 responses.

Thank you to everyone who participated or shared it; the insights gathered were eye-opening.

This article illustrates what the community had to say.

Get my updates in your inbox

Register to be the first to receive my new articles on Laravel, DevOps, my projects, and the future of the Laravel package ecosystem.

                <span>Subscribe</span>
                <span><svg xmlns="http://www.w3.org/2000/svg" height="24" width="24" viewBox="0 0 24 24">
    <g stroke-linecap="round" stroke-width="2" fill="currentColor" stroke="none" stroke-linejoin="round">
        <g>
            <circle cx="4" cy="12" r="3"></circle>
            <circle cx="12" cy="12" r="3"></circle>
            <circle cx="20" cy="12" r="3"></circle>
        </g>

    </g>
</svg></span>



            Email sent! Check your inbox to complete your signup.

No spam. Unsubscribe anytime. Thank You.

Who responded?

To ensure the data reflected active ecosystem users, I first asked how often respondents develop new features or applications using Laravel.

82% develop new Laravel features Daily or Weekly. That number grows to 94% if we include monthly respondents. This tells me the majority of you aren't just maintaining legacy code; you're actively choosing Laravel for new work. That's awesome to see.

(Going forward, the data below focuses on this active daily/weekly/monthly cohort to ensure relevance.)

How often do you develop new features or applications using Laravel?

The "Build vs. Buy" Mentality

When needing standard functionality (e.g., SEO, Media handling, Payments), what is the default reaction? Do developers reinvent the wheel or look for existing solutions?

The results show a strong preference for existing solutions. 96% of respondents indicated they either immediately look for existing packages/SDKs (65%) or search for packages first before potentially deciding to build it themselves (31%).

This confirms that Laravel developers prefer not to rebuild standard functionality unless forced to. Remember that detail for later.

When you need standard functionality what is your default reaction?

Where do developers find packages?

I was curious if my personal habit of just Googling everything was normal. It turns out, it is. (Note: Respondents could select multiple options).

Unsurprisingly, Web Search (74%) dominates. However, it is closely followed by Packagist (51%) and community news sources like Laravel News or newsletters (49%). Interestingly, developers seem to trust curated news sources and general web results significantly more than GitHub search (42%) or social media feeds (19%) when looking for tools. So, a bit surprisingly, this means we choose to trust other developers' recommendations via news sites more than random posts on social media.

Where do you primarily go to find Laravel packages today?

How heavy are our composer.json files?

I asked how many third-party packages (excluding default Laravel dependencies) are in an average project to gauge the "baggage" we're willing to carry.

Over half of the respondents (54%) fall into the 6–15 package range. Given standard best practices today (involving tools like PHPStan, Pint, Debugbar, or Telescope), this feels normal.

I was surprised that 38% managed to keep projects between 0 and 5 packages, that is impressive discipline! Honestly, how do you manage to keep it so low? Please send me a DM, I'm very curious. Finally, 7% have 16 or more packages. That seems heavy, how long does your composer update take at that point? Luckily Composer is fast, but still.

Roughly how many third-party packages are in your average project?

The Vetting Process

How much time do you spend researching before typing composer require?

61% spend between 5 and 30 minutes.
<5 minutes was the next largest group with 19%
30% spend more than 30 minutes doing a deeper dive.

This suggests that for the majority, the criteria chosen for selection needs to be scannable quickly, things like update recency, documentation quality, and popularity, rather than deep code audits. We have what Italians call "grilletto facile" (a quick trigger) for packages that look good on the surface.

How much time do you typically spend researching and auditing a package

When asked to rank the most important factors when choosing between similar packages, the results confirmed this:

Recency of updates / Maintenance status
Documentation quality
GitHub Stars / Popularity
Author reputation

The quality and frequency of updates are clearly king.

What is the most important factor when choosing between two similar packages?

A related note on compatibility: I also asked if you verify if a package supports your specific tech stack (e.g., Blade vs. Vue/React) before installing. 56% said yes, as compatibility is often an issue. 32% mainly use headless packages, and 11% don't check too much, planning to adapt the code anyway.

Do you verify if a package supports the specific tech stack you use before installing?

The Biggest Frustrations

This was the most critical part of the survey: what makes developers unsatisfied with the current ecosystem?

It is a statistical tie for the top frustration. 70% cited lack of documentation or usage examples , while virtually the same amount cited the issue of too many abandoned or outdated packages cluttering search results.

We have all experienced searching for functionality and finding five packages that haven't been updated since Laravel 8.

In third place (28%) was the difficulty of comparing features between similar packages. And finally, not knowing if a package is compatible with my Laravel version represents 13% of results.

What is your biggest frustration when searching for a package?

The Community Wish-list

I finally asked an open-ended question: "If you could wave a magic wand and improve one thing about the Laravel ecosystem today, what would it be?"

I received 32 wonderful, detailed responses. While some covered broader topics, the vast majority focused specifically on the pain of managing third-party packages. Here are some representative voices from the community:

On the broader community:

"...less expensive Laracons..." . I can understand this! Have you heard of LaravelLive.jp? The price is very low and japan is japan, we could even meet for a coffee there.
"More popularity with employers" . We all want this.
"Laravel patterns often don't scale well. More education around team-oriented patterns..."
"More focus on plain Laravel + Blade" and "I want to make it more type safe..."

On packages specifically (this is where it got really interesting):

"Making keeping packages up to date for each Laravel version the norm. Many packages are abandoned after a few versions."
"Standardize package info presentation to include age of project, last update, version compatibility, preq, open issues."
"Less fragmentation of third party packages would be nice."
"Reduce the number of duplicate packages that do the same or similar functions."
"A Laravel centric site with packages including their usages... a dedicated site would be better."

I also saw some direct debate in the responses, like requests for "More livewire support, fewer paid libraries" sitting right next to a simple "get rid of livewire". The community has strong and mixed feelings!

Conclusion

The data paints a clear picture: Laravel developers want to use packages, but the friction involved in finding reliable, well-documented, and up-to-date tools is a major pain point. The ecosystem is vibrant, but that vibrancy creates noise that is hard to filter.

The recurring theme in your open-ended responses was a desire for a centralized, standardized way to evaluate packages specifically for Laravel. Those suggestions literally gave me an idea.

Inspired by this data and your specific feedback, I started working on LaraPlugins.io as an attempt to address these frustrations. It’s a new directory focused on helping developers find, compare, and check maintenance status for Laravel-specific packages. It can even be connected to your ai agent with a simple fast mcp connection now! See how here https://laraplugins.io/mcp

The beta of the site is up but with an initial health score algorithm.

I don't pretend to have the perfect way to judge article healthy so please give the site a try then send me a feedback on the site health score system.

Only a collective effort can produce something really useful to all of us.

in the incoming AI development having a trustworthy directory would make AI agents able to pick healthy packages for the development project.

P.S. Laravel is a trademark of Taylor Otwell. LaraPlugins.io is an independent, community-driven directory and is not officially affiliated with, endorsed by, or sponsored by Laravel or Taylor Otwell. Trademark usage is intended solely to identify the Laravel framework and its ecosystem packages.

LaraPlugins Devlog: Sub-Second Search, Vendor Profiles, and Building an AI Brain (MCP)

Daniel, Petrica Andrei-Daniel — Sun, 18 Jan 2026 18:44:26 +0000

When you are building for scale, technical debt eventually knocks on the door, this weekend, I answered. Here is what shipped:

Sub-Second Search & Pagination Fixes

Thanks to community feedback, I prioritized the "slow search" issue. Digging into the metrics, I found the culprit: classic N+1 query problems that were dragging down the /plugins list response times.

I optimized the underlying queries and eager-loaded the necessary relationships.

Get my updates in your inbox

Register to be the first to receive my new articles on Laravel, DevOps, my projects, and the future of the Laravel package ecosystem.

                <span>Subscribe</span>
                <span><svg xmlns="http://www.w3.org/2000/svg" height="24" width="24" viewBox="0 0 24 24">
    <g stroke-linecap="round" stroke-width="2" fill="currentColor" stroke="none" stroke-linejoin="round">
        <g>
            <circle cx="4" cy="12" r="3"></circle>
            <circle cx="12" cy="12" r="3"></circle>
            <circle cx="20" cy="12" r="3"></circle>
        </g>

    </g>
</svg></span>



            Email sent! Check your inbox to complete your signup.

No spam. Unsubscribe anytime. Thank you.

Result : Search and pagination now load in under 1 second. Check here to se how i built the site for that

The Lesson : Even experienced developers miss N+1 queries sometimes. This reinforces why optimization isn't just "nice to have" it is a core feature that requires constant observability. When you can't measure it, you can't fix it.

LaraPlugins screenshot, what will be your next plugin?

New "Vendor" & "Maintainer" Pages

I have started rolling out dedicated pages for plugin vendors and maintainers.

Current State : Basic listings are live, with clean profiles for major vendors like Spatie, BeyondCode, and others.

Spatie Vendor Page, showcasing all the plugins where they are the vendor.

The Goal : Turn these into rich profiles with insightful stats like:

Total downloads across all packages
Average health score of maintained packages
Update frequency and responsiveness
Community trust indicators

What specific data points would you want to see on a Maintainer's profile to judge the quality of their work? Let me know in the comments your feedback drives this roadmap.

With these new pages my site reached the 10k pages count, are you wondering how I host it to allow for such a size? Check my stack in this dedicated article.

Building the "Brain" (MCP Server)

This is the most exciting update. I am actively building a Model Context Protocol (MCP) server for LaraPlugins.

The Vision : Enable AI agents (like Claude or Cursor) to query my directory directly. Instead of hallucinating packages or using outdated packages due to their cut date, your AI editor could ask:

"What's the best PDF generation package for Laravel?"
"Show me the most actively maintained charting libraries"
"Find packages that solve authentication with minimal overhead"

The AI agent would query LaraPlugins in real-time, pulling verified, healthy packages with actual health scores containing "pdf generation" or pdf. No more guessing. No more outdated recommendations. The agent would be then able to choose a plugin based on their health status, php and laravel compatibility, maintenance status and more.

Status : The server is live, but search integration is still a Work In Progress. I am currently refining the caching strategy, since Cloudflare cannot easily cache these dynamic API hits, to ensure stability and performance before opening it to a broader audience.

Why This Matters: Right now, AI models hallucinate package recommendations because they were trained on static data. By providing a real-time MCP interface, I hope to solve a real problem: How do AI agents find the healthiest, most actively maintained Laravel packages?

Quality of Life Updates

Improved version compatibility badges on plugin cards (clearer visual)
Refined the "Health Score" algorithm (still tuning this, signals are hard!)
Added breadcrumb navigation to vendors and maintainers for improved discoverability

Next Steps

Tomorrow is for polishing. I will be finalizing the MCP search integration and ensuring the new Vendor index pages are SEO-ready for organic discovery.

For you : Give the new search a spin and tell me if it feels snappier. Does the sub-second speed make a difference in how you explore packages? As always, your feedback drives this roadmap.

What's coming next : In February, I am building curated collections ("Featured: Filament Ecosystem", "Top 10 Database Packages") and opening early access to the MCP server for beta testers. If you want to be notified when the MCP is ready, drop a comment or reach out in any way.

Until then, happy package hunting.

How I built a high-performance directory with Laravel Octane and Filament

Daniel, Petrica Andrei-Daniel — Sun, 11 Jan 2026 12:06:03 +0000

Back when I launched the survey on the state of the Laravel plugin ecosystem, one statistic stood out immediately:

70%+ of developers spend between 5 and 30 minutes just to determine if a plugin is healthy enough to install

This is " Dependency Anxiety." It’s the recurring cost we pay every time we search for a package or audit our composer.json. Is this package abandoned? Does it support PHP 8.5? Are the tests passing? Multiply those 30 minutes by every package in your stack, and the productivity loss is massive.

To solve this, I built Laraplugins.io , an automated intelligence tool designed to do that vetting for you and display it to you so you can get a pretty good idea of the health status in seconds.

I launched LaraPlugins.io on product hunt today. Please help me get it in front of developers with and upvote and tell me in the comments over there what you would change about my health score algorithm.

Upvote on product hunt

The Architecture: Built for Speed and Scale

As a DevOps and developers, I wanted the infrastructure to be as robust as the data it serves. I designed a high-performance architecture capable of handling heavy traffic on a single multi-site VPS running over 30 projects and nearly 100 Docker containers. here more info if curious about my production-ready FrankenPHP setup.

The Stack

The application runs on a modern, containerized stack optimized for concurrency and low latency:

Runtime: Laravel Octane with FrankenPHP
Routing: Traefik Reverse Proxy
Caching: Redis & Cloudflare CDN
Orchestration: Docker Compose

Request Lifecycle

The flow is designed to minimize hit-rate on the application server:

User -> Cloudflare CDN -> Traefik -> FrankenPHP (Octane) -> Redis

Edge Caching: Public pages are cached by Cloudflare for 2 hours. This drastically reduces server load by serving static content directly from the edge.

Efficient Routing: When traffic reaches my VPS, Traefik handles the routing. It ensures fast, reliable directing of requests across the dozens of micro-services and sites running in parallel.
In-Memory Bootstrapping: Finally, Laravel Octane and FrankenPHP take over. Because the application stays booted in memory, we eliminate the traditional PHP-FPM overhead, ensuring responses are nearly instantaneous.

The "Health Score" Algorithm

The core of Laraplugins.io is the Health Score. It’s not a magic number, but an aggregate of about 10 key signals that determine a package's viability.

1. Update Recency

This is the baseline. Developers need active maintenance. I track the last commit date and release history to ensure you aren't installing abandonware.

2. Version Compatibility

I rigorously check composer.json constraints to verify active support for modern Laravel and PHP versions. If a package is stuck on Laravel 9, you need to know.

3. The "Archived" Penalty

If a project is archived on GitHub, we apply a heavy penalty. This marks a definitive end of life for the package, and it should generally be avoided for new projects.

4. Normalized Download Stats

We monitor download counts, but we’ve intentionally reduced their weight in the final score. We want to highlight quality, not just popularity. This ensures new, high-quality plugins aren't unfairly penalized just because they haven't been around for years.

5. Best Practices & Quality

Finally, we scan for indicators of a mature engineering culture: presence of CI/CD pipelines, active test suites, and valid licenses.

Feedback Welcome

The Health Score is currently in beta. I’m building this for the community, so I want to hear from you. What signals do you look for before composer require-ing a new package?

Let me know your thoughts, and check out the launch onproduct hunt please

My new project: Coz.jp

Daniel, Petrica Andrei-Daniel — Sun, 09 Nov 2025 06:06:40 +0000

Hello, Dev Community! I'm excited to finally pull back the curtain on my latest side project: Coz.jp, a new link shortening service.

While "yet another link shortener" might sound simple, the goal here was to build something fast, reliable, and deeply integrated, all while using a modern and scalable tech stack. I want to share a little bit about what it does and the architecture I chose.

Why I Built It

As a developer, I've always needed a link shortener that gives me full control after the link is created. That's what Coz.jp is all about: fast creation, but also the ability to go back and fix errors by editing the target URL, or deleting the link entirely. It focuses on:

Fast and Reliable URL Shortening: Speed is non-negotiable for link redirects.

Complete Link Management: Easily fix mistakes or update destinations after publishing.

Privacy-Friendly Analytics: Gain insights without compromising user security.

The Technical Core: My Stack

For a project like this, I needed a setup that was robust, easy to deploy, and scalable. I went with a modern, containerized architecture that uses some of my favorite tools:

Framework: Laravel The back-end is powered by Laravel. Its elegant syntax and robust features made developing the API endpoints and the link management dashboard incredibly efficient. Laravel's Eloquent ORM provides a secure and structured way to handle the thousands of daily redirects.

Containerization: Docker Compose Everything runs inside Docker Compose. This ensures that the local development environment is an exact mirror of the production environment, eliminating the dreaded "it works on my machine" problem and making deployment rock-solid.

Database: MySQL The reliable backbone of the application is MySQL. It handles the quick lookups required for redirects and securely stores all the user and link data.

Reverse Proxy: Traefik I used Traefik as the edge router. Traefik handles all the incoming traffic, manages HTTPS certificates automatically, and routes traffic efficiently to the correct Docker containers. This setup gives me excellent performance and a truly scalable, production-ready infrastructure.

Ready for Your Workflow

One of the key features I focused on was developer and business integration. Coz.jp offers:

Full API Integration: Ready for you to integrate into scripts or custom applications.

N8N Node: For those using low-code automation, I've built an n8n node to allow seamless integration into your automated workflows.

You can manage your links with a simple email verification process, ensuring only you control your shortened URLs.

Try It Out!

I'd love for you to check it out. You can login and Start your free trial today.

A Production-Ready Laravel Architecture with Traefik and FrankenPHP

Daniel, Petrica Andrei-Daniel — Sun, 09 Nov 2025 05:49:04 +0000

Laravel is a very performant framework, but a standard architecture has one big flaw derived from how PHP works: It has to rebuild the entire framework on every single request.

Even with optimizations, this process still takes 40 to 60 ms on my machine with PHP 8.4. Luckily, for years, the PHP and Laravel worlds have had a solution that dramatically reduces this load time: Laravel Octane and FrankenPHP. The booting time for the Laravel framework can drop to just 4 to 6 ms per request. Incredible, isn't it?

Now, if you're new to Laravel Octane or FrankenPHP, you may wonder: How is this possible?

The simple answer is that the framework is kept in memory. After FrankenPHP starts, Laravel is always ready to serve requests without a full reboot. The real explanation is more complex and out of scope for this article. If you're curious, you can read the official Laravel Octane and FrankenPHP docs for a deeper dive.

read the full article at: DanielPetrica.com

Laravel and Traefik: Dynamic Configuration for Effortless Multi-Domain Management

Daniel, Petrica Andrei-Daniel — Sat, 13 Sep 2025 16:34:05 +0000

After finishing my full-time employment, I suddenly found myself with a lot of free time. To make use of it, I decided to stay up to date by working on some new side projects and experiments.

The Challenge: Dynamic Multi-Domain Support in Laravel with Traefik

One of these experiments was related to supporting multiple domains in Laravel in a dynamic way. I initially found this relatively easy, but in a hypothetical production environment, handling everything automatically would not be quite as seamless. For example, Traefik usually relies on label-based or file-based configurations, which means the dynamic part disappears entirely, leaving you with one big configuration file to manage manually.

Discovering Traefik’s HTTP Configuration Provider

Just when I was about to abandon this project, I remembered the existence of the HTTP configuration provider in the Traefik documentation. According to the docs, it allows you to configure Traefik by pointing it to a specific URL that returns either a JSON or YAML configuration.

That’s when inspiration struck: I could configure Laravel to expose a JSON configuration representing the router setup. This configuration would then point to a single service defined by Docker service labels.

Setting Up the Docker Service Labels

With some blind trust, I jumped into implementing the idea. Creating the service labels was fairly easy. I also included a default domain host to ensure I always had an accessible admin interface. Here’s the snippet from my compose.yaml file:

     labels:
            - traefik.enable=true
            - traefik.http.routers.example-name-https.rule=Host(`example-name`)
            - traefik.http.routers.example-name-https.tls=true
            - traefik.http.services.example-name-service.loadbalancer.server.port=80
            - traefik.http.routers.example-name-https.tls.certresolver=cloudflare
            - traefik.http.routers.example-name-https.entrypoints=websecure
            - "traefik.http.routers.example-name-https.middlewares=forward-auth_blog-network"
            - "traefik.http.middlewares.forward-auth_example-name.headers.customrequestheaders.X-Forwarded-Proto=https"
            - "traefik.http.middlewares.forward-auth_example-name.headers.customrequestheaders.X-Forwarded-Host=example-name"

Generating the Dynamic Configuration in Laravel

On the Laravel side, I was able to expose a JSON structure fairly easily. Since I had a collection of domains to generate, I prepared a multidimensional array like the one in the snippet below:

$config['http']['routers'][$domainName . '-https'] = [
    'rule' => 'Host(`' . $host . '`)',
    'tls' => true,
    'service' => $serviceName,
    'middlewares' => [$middlewareName]
];
$config['http']['middlewares'][$middlewareName] = [
    'headers' => [
        'customrequestheaders' => [
            'X-Forwarded-Proto' => 'https',
            'X-Forwarded-Host' => $host,
        ]
    ]
];

If you’re already familiar with YAML or Traefik configuration, you can see this structure is very similar to the earlier Docker labels example.

Configuring Traefik to Consume Laravel’s Endpoint

At this point, all I had to do was tell Traefik to call this new Laravel-powered endpoint. In traefik.yml, I went to the providers section and added the following HTTP provider configuration:

http:
  endpoint: "https://admin.example.com/internal/traefik_config"
  pollInterval: "15s"
  headers:
    customRequestHeaders:
      X-Traefik-Passphrase: "yoursecrettoken"

This setup is straightforward. You specify the endpoint (reachable from the Traefik container), configure the polling interval to tell Traefik how often it should check for updates, and optionally add headers to secure requests.

The Setback: JSON Format Issues

At this point I tested everything, hopeful that it would just work. Obviously, that wasn’t the case. After trying different versions and settings — and reading through forum discussions — I realized nobody had been able to get the JSON HTTP provider working properly. It made me suspect the documentation was outdated, so I started looking for alternatives.

The breakthrough came when I decided to serve the configuration in YAML instead of JSON. I chose the symfony/yaml library to convert my Laravel arrays into YAML format easily. The updated Laravel response looked like this:

return response(
    content: Yaml::dump($config, 10),
    status: 200,
    headers: ['Content-Type' => 'text/yaml']
);

Final Results and Practical Benefits

After configuring Cloudflare to point to the correct server and managing domains through Laravel, I achieved the dynamic multi-domain setup I aimed for. Traefik not only serves the domains correctly but also respects domain removals—after the polling interval, removed domains cease to be reachable.

This seamless integration between Laravel and Traefik solves a complex problem and will form the foundation for a new tool I’m developing to improve Laravel developers’ workflow.

Want to Stay Updated?

If you’re interested in early updates, pre-launch offers, or beta invitations for this tool, please subscribe to my website. Your support means a lot on this journey!

Summary

This project is a proof of concept showcasing how dynamic domain routing can be effectively managed by Laravel in conjunction with Traefik, combining automation and flexibility for scalable deployments.

Self-Hosting n8n with Docker Compose and Traefik for AI-Powered Workflow Automation

Daniel, Petrica Andrei-Daniel — Mon, 07 Jul 2025 22:27:10 +0000

Tired of juggling apps and manual tasks?

Self-hosting n8n could be a game-changer. It’s a powerful, open-source automation tool, and setting it up yourself using Docker Compose and Traefik makes it both flexible and super accessible. I'll walk you through the setup and show off the cool AI features that really make n8n shine.

So, what exactly is n8n?

Think of n8n as your digital duct tape. It's a free, open-source tool that lets you visually connect different apps and services to automate just about any workflow you can imagine. Drag and drop nodes to build sequences that handle all those boring, repetitive tasks for you. It saves a ton of time and gives you way more control over your data.

Want my expertize applied to you company? Contact me

n8n's Secret Sauce: AI Power

n8n isn't just about simple "if this, then that" rules anymore. It's evolved into a legit platform for building smart, AI-driven applications. How? By using something called "agentic AI." This means your workflows can actually make decisions, understand context, and interact with your data intelligently, not just follow a rigid script.

Here’s what makes the AI side so powerful:

The AI Agent Node: This is the brains of the operation. It processes info, makes choices, and uses built-in "tools" to talk to other apps or data sources. It connects to big AI models like OpenAI's GPT, Google's Gemini, or Anthropic's Claude to understand what you need and give smart replies.
LangChain Built Right In: n8n plays nicely with LangChain, a popular framework for building complex AI logic. This means you can create chains of AI actions or even agents that decide which actions to take next, all within your workflow.
Talk to Your Data (Vector DBs): Connect n8n to vector databases like Pinecone or Supabase, or use its simple built-in memory store. This is key for building RAG systems – where the AI can pull answers from your own private docs or data, making it super relevant and useful.
Endless Possibilities: With these tools, you can build things like: smart chatbots for customers, AI assistants that summarize your emails and book meetings, or systems that dig insights out of messy, unstructured data.

What You'll Need Before We Start

Don't sweat it, it's mostly standard gear for self-hosters:

Docker & Docker Compose: Make sure they're installed and running. (Docker Compose usually comes bundled with Docker these days).
Traefik: You'll need this running for your reverse proxy. (If you're not set up yet, check out this guide on configuring Traefik).
A Domain Name: Grab a domain or subdomain to point to your n8n instance (places like Namecheap often have domains starting around $2).

The Docker Compose Setup

We'll use a compose.yaml file to spin up both n8n and its database (we're using PostgreSQL here). Traefik integration is handled smoothly with labels right in the file – it takes care of routing traffic and HTTPS automatically.

Here's the compose.yaml file:

version: '3.8'

services:
  n8n:
    image: n8nio/n8n
    container_name: n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678" # Only exposed locally, Traefik handles external access
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB} # Comes from .env file
      - DB_POSTGRESDB_USER=${POSTGRES_USER} # Comes from .env file
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD} # Comes from .env file
      - NODE_FUNCTION_ALLOW_EXTERNAL=langchain # Important for LangChain nodes!
    volumes:
      - n8n_data:/home/node/.n8n # Persist your workflows and settings
    networks:
      - n8n
      - traefik
    depends_on:
      - postgres
    labels: # Traefik magic happens here
      - "traefik.enable=true"
      - "traefik.http.routers.n8n.rule=Host(`n8n.yourdomain.com`)" # <<< REPLACE WITH YOUR DOMAIN!
      - "traefik.http.routers.n8n.entrypoints=websecure"
      - "traefik.http.routers.n8n.tls.certresolver=myresolver" # <<< REPLACE 'myresolver' with your Traefik resolver name!
      - "traefik.http.services.n8n.loadbalancer.server.port=5678"

  postgres:
    image: postgres:14
    container_name: n8n_postgres
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB} # From .env
      - POSTGRES_USER=${POSTGRES_USER} # From .env
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD} # From .env
    volumes:
      - postgres_data:/var/lib/postgresql/data # Persist your database
    networks:
      - n8n

volumes:
  n8n_data:
  postgres_data:

networks:
  n8n:
  traefik:
    external: true # Assumes your Traefik network already exists

Don't forget the .env file!

Create a .env file in the same folder as your compose.yaml to keep your database secrets safe:

POSTGRES_DB=n8n
POSTGRES_USER=n8nuser
POSTGRES_PASSWORD=a_very_strong_and_secret_password # Make it a good one!

Let's Get n8n Running!

Make a Home: Create a directory for your n8n setup and save both the compose.yaml and .env files inside it.
Traefik Takes Over: Traefik should automatically spot your new service, grab an SSL certificate, and start routing traffic to https://n8n.yourdomain.com.
Almost There! Once the containers are running (give it a minute after the command finishes), open your domain in a web browser. The n8n web interface will greet you and guide you through the initial user setup.
Breathe Easy: Notice the n8n port (5678) is only exposed locally on your server. Traefik is the secure gatekeeper handling all outside traffic. we can go even further, on my server I don't even expose that port internally as it's not needed and better not expose things we don't need.

Fire it Up: Open a terminal, navigate to that directory, and run:

docker compose up -d

That's it! Your self-hosted n8n automation playground is ready. Go build something awesome!

Want to learn how to secure your database? I have an article about that

[

Easy database backups with docker-compose

I implemented a backup tool for my new docker compose and traefik stack to help save and restore my databases and avoid loss of data

Daniel PetricaDaniel, Andrei-Daniel Petrica

](https://danielpetrica.com/easy-database-backups-with-docker-compose/)

If N8N is not your sauce active pieces is actually a great compelling alternative too

[

Install Activepieces with Docker & Traefik for self-hosted automation

Activepieces is an open-source automation tool enabling users to create custom workflows across many apps. We’ll install it on docker and traefik

Daniel PetricaDaniel, Andrei-Daniel Petrica

](https://danielpetrica.com/installing-activepieces-with-docker-compose-and-traefik/)

Want my expertize applied to you company? Contact me

Tired of Manual Calendar Management? I Was Too. So I Built This Tool

Daniel, Petrica Andrei-Daniel — Mon, 07 Jul 2025 22:21:06 +0000

Lately, I’ve been trying to organize my life better. Like many people, I kept hearing about calendar blocking and other productivity techniques.

But let’s be honest — am I really expected to manually create countless little event blocks, keep track of holidays, and constantly update my calendar?

No thanks. Instead, I built a tool that does it all for me — fast, efficiently, and with no friction.

What the Tool Does

This streamlined web app lets you build complex, recurring schedules in just a few clicks. Define your time blocks once, customize your settings, and instantly generate a complete calendar file ready to import into any major calendar application.

Want my expertize applied to you company? Contact me

Key Features

Multiple Time Slots

Create recurring events with custom titles, days, and times.

Flexible Scheduling

Set schedules on any combination of days — weekdays, weekends, or fully custom patterns.

Smart Off-Days

Exclude specific dates, such as holidays or vacations, where your recurring events shouldn’t apply.

Time Tracking

Get an overview of how many events will be created and the total time commitment involved.

Dark Mode Support

Includes automatic dark mode detection for a more comfortable viewing experience.

Responsive Design

Works seamlessly on both desktop and mobile devices.

Ideal Use Cases

Work Schedules — Block out time for focus sessions, meetings, or project work
Fitness Routines — Plan gym sessions, yoga classes, or training blocks
Study Plans — Organize consistent learning sessions across subjects
Personal Projects — Allocate time for hobbies, side gigs, or creative work
Team Coordination — Create shared, recurring schedules for collaborative tasks

How It Works

Set Your Date Range Define the start and end dates for your schedule.
Configure Time Slots Add as many recurring time blocks as needed, each with its own settings.
Exclude Off-Days Remove holidays, breaks, or other non-working days from your schedule.
Generate and Download Export your setup as a standard .ics calendar file, compatible with Google Calendar, Outlook, Apple Calendar, and others.

Try It Out

If you're tired of repeating the same scheduling steps week after week, this tool will change how you manage your time:

Visit the Periodic Schedule Calendar Generator

Why This Matters

Manual scheduling is tedious and error-prone. This tool eliminates that hassle. With just a few clicks, it generates hundreds of recurring events, accurately accounts for off-days, and gives you insight into your total time allocation before you even start.

Technical Highlights

Built using Vue 3 and Tailwind CSS
Pure JavaScript generation of .ics files
No external dependencies beyond CDN libraries
Fully responsive design
Compatible with all major calendar platforms

Built with Vue.js. Designed for clarity. Powered by smart scheduling logic.

Say goodbye to manual calendar entry — and take control of your time.