infocyph/foundation is the performance-first application composition layer for
the Infocyph PHP ecosystem. It owns application bootstrap, explicit runtime
selection, provider graph composition, and application-level policy while
specialist libraries retain their domain engines and public APIs.
Foundation requires PHP ^8.4.
composer require infocyph/foundationThe package exposes the infbyte Composer binary:
vendor/bin/infbyte list
vendor/bin/infbyte --version
vendor/bin/infbyte help module:installApplications using the standard root script can run the same commands with
php infbyte. Metadata-only list, help, version, and completion commands do not
boot the application.
Select one of Foundation's four runtimes explicitly:
use Infocyph\Foundation\Foundation;
$web = Foundation::web(['base_path' => dirname(__DIR__)]);
$cli = Foundation::cli(['base_path' => dirname(__DIR__)]);
$worker = Foundation::worker(['base_path' => dirname(__DIR__)]);
$scheduler = Foundation::scheduler(['base_path' => dirname(__DIR__)]);Foundation never infers the runtime from PHP_SAPI. Non-web commands, worker
units, and scheduled invocations use stable semantic InterMix scopes. Web request
and scope ownership belongs to Webrick's compiled execution plan, so a minimal
route can remain Request-free and scope-free.
Application providers are assigned by runtime in bootstrap/providers.php:
return [
'common' => [],
'web' => [],
'cli' => [],
'worker' => [],
'scheduler' => [],
];Providers contribute deterministic graph definitions before production compilation; production boot does not reopen the mutable development container.
See Architecture and lifecycle, Configuration, and the Foundation 3 migration guide for the complete runtime contract.
The application modes are independent of the HTTP host. Ordinary PHP/FPM can use Webrick's SAPI path. Applications selecting Runwire use Webrick's Runwire bridge; Runwire owns native portable/prefork execution and its FPM, FrankenPHP, RoadRunner and Swoole/OpenSwoole host adaptation. Foundation supplies the compiled application and its scoped services.
Runwire is optional and does not activate merely because it is installed. See Runtime hosting for ownership, selection and the verification boundary.
Foundation modules describe optional application capabilities rather than package
names. CacheLayer is a direct Foundation dependency and core cache infrastructure,
but the cache capability still remains cold until explicitly selected. Other
optional packages such as DBLayer, Omnibus, TalkingBytes, Epicrypt, Pathwise,
ReqShield, OTP, or WebAuthn likewise do not activate themselves merely because
they are installed.
| Specialist module | Implementation |
|---|---|
auth |
Foundation auth with optional OTP and WebAuthn providers |
communication |
TalkingBytes |
database |
DBLayer |
filesystem |
Pathwise |
messaging |
Omnibus |
security |
Epicrypt |
validation |
ReqShield |
The catalog also retains four built-in entries for configuration and schema
operations: logging, operations, resources, and session. They require no
additional Composer packages and cannot be removed. CacheLayer is core
infrastructure, outside the module catalog; use cache:schema:status and
cache:schema:install for core cache schemas. Notifications are native and use
TalkingBytes only when its email integration is selected.
Use the module commands to inspect, install, configure, and provision a specialist capability:
php infbyte module:list
php infbyte module:show database
php infbyte module:install database
php infbyte module:config:publish messaging
php infbyte module:schema:status authFoundation composes these libraries without replacing their native query, cache, filesystem, validation, communication, cryptography, or messaging APIs. See Modules for package mappings, aliases, activation rules, and schema ownership.
The CLI provides explicit commands for the application lifecycle. Common entry points include:
php infbyte app:ready
php infbyte migrate --pretend
php infbyte schedule:run
php infbyte worker:list
php infbyte runtime:reload
php infbyte optimizeProduction deployment publishes one immutable Foundation release generation. The generation owns the normalized config snapshot, compiled Webrick web bundle, compiled InterMix CLI/worker/scheduler containers, worker topology, and trust metadata. InterMix generated PHP remains the native DI production cache and is loaded directly through its own manifest/ProductionContainer path; Foundation does not redirect compiled containers through CacheLayer. Production release loading does not fall back to project route, provider, or config discovery when a generated artifact is missing or invalid.
Run php infbyte list for the active command catalog. Generated artifacts are
deployment-owned and should not be committed. Use php infbyte optimize:clear
for explicit build-plane cleanup.
Operational behavior and safety constraints are documented in CLI, schedules, and workers, Messaging, and Operations.
The documentation index links the focused guides for HTTP,
authentication, sessions, database, storage, communication, JSON resources,
logging, testing, security, and Foundation 3 migration. Configuration templates
under resources/config/ are the canonical key-by-key reference.
Run the complete release guard before publishing:
composer ic:release:guardThe Security & Standards workflow adds the PHP 8.4/8.5 lowest/stable matrices, service-backed integration checks, and a clean production install. Run the representative workload separately when validating performance-sensitive changes:
composer benchmark:representativeOnly compare numeric benchmark results from matching, explicitly stable environments.