Apc Bundle Laravel Package

Getting Started

The bundle is a thin Symfony integration: it registers one console command whose only job is to flush APC's opcode/user cache. There is no configuration surface, no service to inject, no runtime behavior — treat it as a deploy-time utility, not application code.

Minimal path:

1. Install it:

   composer require icedevelopment/apc-bundle
   

2. Register the bundle in config/bundles.php (Symfony 4+):

   return [
       // ...
       IceDevelopment\ApcBundle\ApcBundle::class => ['all' => true],
   ];
   

   The exact class name/namespace lives under vendor/icedevelopment/apc-bundle/src/; confirm it there before pasting, since the package has no docs and a 2022 release. On Symfony 3.x it goes in AppKernel::registerBundles().
3. Confirm the command name — listing is faster than guessing:

   bin/console list | grep -i apc
   

   You'll typically see something like apc:clear. Run bin/console help apc:clear to see options before wiring it into anything.
4. Sanity-check the environment first:

   php -m | grep -i apc
   

   If nothing prints, the command has nothing to act on.

First real use case: running it at the end of a deploy, right after cache:clear/cache:warmup, so a stale opcode/user cache doesn't serve the previous release's classes. That is the entire value proposition — put it in the deploy script, then forget it exists.

Implementation Patterns

Deploy pipeline hook. The most common integration is a line in your release script, ordered after code sync and Symfony cache warmup:

bin/console cache:clear --env=prod --no-debug
bin/console cache:warmup --env=prod --no-debug
bin/console apc:clear --env=prod

Keep it late in the sequence — clearing APC before cache:warmup just forces recompilation of code you're about to change anyway.

Makefile / task runner target. Wrap it so nobody has to remember the exact command:

apc:
	php bin/console apc:clear --env=prod

Multi-host deploys. The command runs in the process it's invoked from, so on a load-balanced fleet you must either SSH each host and run it locally, or rely on your deploy tool's per-host execution (Capistrano-style on roles(:app), Ansible delegate_to, etc.). A single invocation on a build box clears nothing on the web tier.

Programmatic invocation (rare, but useful for a custom admin command):

$application = new Symfony\Bundle\FrameworkBundle\Console\Application($kernel);
$application->setAutoExit(false);
$application->run(new ArrayInput(['command' => 'apc:clear']));

Only reach for this if you're composing several clear operations behind one operator-facing command; otherwise invoke the CLI directly.

Pair with Symfony's own cache. These are two independent caches. cache:clear empties var/cache; this bundle empties APC. A correct production deploy usually wants both, and a stale-class bug after deploy is more often APC/OPcache than Symfony's pool — so run both in that order.

CI/CD integration tips. Gate the step on production-like environments only; there's no reason to flush APC in dev, where you'll want the cache warm for speed. If your pipeline runs the command inside a container that isn't the web container, it will succeed and accomplish nothing — verify you're executing in the same SAPI/container that serves traffic before trusting the green check.

Gotchas and Tips

• CLI and web share nothing. This is the pitfall that sinks this package for most teams. APC/APCu state is per-SAPI and per-process. Running bin/console apc:clear clears the CLI cache; your php-fpm/Apache workers keep their own. Unless you're clearing via an HTTP endpoint hit by a real web request, the deploy step is a no-op for users. Check how you serve traffic before assuming it works.
• apc.enable_cli must be on for APC to even be active in CLI, otherwise the command finds an empty or absent cache and may exit successfully without doing anything. Look for apc.enable_cli=1 in your CLI php.ini.
• APC vs APCu vs OPcache. The original APC extension is dead — it does not exist on PHP 7+. Modern stacks use APCu (user cache) and OPcache (bytecode). A 2022 bundle named "Apc" most likely targets the legacy extension or APCu; verify which function it calls (apc_clear_cache() vs apcu_clear_cache()). If you're on OPcache, this package is the wrong tool — use opcache_reset() via a web endpoint or cachetool.
• Silent no-ops. Expect the command to fail quietly (or warn) if the extension is missing. Never rely on its exit code alone in a pipeline; add a php -m | grep -i apc precondition if the flush is critical.
• Don't confuse it with Symfony's cache. cache:clear will not clear APC, and this command will not clear var/cache. Keep both in the deploy script and document why.
• Low-maintenance, zero-signal package. No stars, no dependents, single 2022 release, no test suite visible. Pin the version in composer.json and treat it as vendored code: read src/ (it's a handful of lines) so you know exactly what it does before it's on the critical path of every deploy.
• Extension points are effectively nil — there's no event, no configuration, no service to decorate. If you need conditional flushing, multi-host fan-out, or APCu/OPcache support, write a small custom command instead of trying to extend this one. It's cheaper than fighting a package with no seams.
• Debugging checklist when "it didn't work": (1) php -m shows the extension in the SAPI you ran from, (2) apc.enable_cli=1, (3) you're on the same container/host as the web workers, (4) the underlying cache is actually enabled (apc.enabled=1), (5) you're not assuming OPcache was affected.