Charm

Charm is an open-source PHP framework and application foundation for business applications, SaaS platforms, APIs, hybrid web applications, and websites. It provides the framework core, project structure, routing, Twig presentation, Eloquent data access, configuration, requests, responses, authentication, migrations, events, queues, scheduled jobs, console tooling, caching, and recurring infrastructure expected across professional web systems.

Laravel and Symfony are mature ecosystems with broad capabilities, large communities, substantial documentation, and many integrations. Charm is not attempting to duplicate their complete scope. Charm selects excellent ecosystem components — including Eloquent, Twig, and Symfony packages — and connects them through a smaller, business-focused application core. It is designed for developers who prefer a more direct structure, a narrower framework surface, strong performance, and fewer conventions that exist mainly to support every possible application category.

No. Charm keeps a compact core, but it provides considerably more application structure and recurring functionality than a minimal HTTP router. Models, Twig views, configuration, authentication, migrations, events, scheduled jobs, queues, console commands, caching, APIs, and development tools are part of the intended application foundation.

No. Framework choice depends on the application, team, ecosystem, hiring needs, integrations, operational model, and expected lifespan. Charm is particularly relevant where its performance, architecture, selected component stack, and business-application conventions match the work. A project that depends heavily on another framework’s ecosystem may be better served by that framework.

Charm is designed primarily for business applications, SaaS products, customer and member platforms, internal tools, APIs, web backends, hybrid applications, and substantial websites. It can also support smaller applications, but its principal value appears where a project benefits from a consistent architecture, authentication, database work, background processing, scheduled behavior, integrations, and long-term maintenance.

Yes. Charm powers Neoground’s own web-based platforms, SaaS products, business applications, APIs, and websites. The framework evolves through this daily production use rather than through hypothetical feature planning alone. As with any framework, an individual application still requires appropriate design, testing, security review, deployment, monitoring, backups, and operational ownership.

The current 3.x line is a stable beta and has been used successfully in Neoground production applications. Version 4 is the upcoming major foundation intended to become the first feature-complete stable release. Because v4 is a major rewrite with breaking changes, external users should pin dependencies, review release notes, test upgrades, and avoid assuming automatic compatibility between major versions.

That depends on the project timeline and tolerance for migration work. The current tagged framework is operational and used in production, but Charm 4 substantially revises and completes the long-term architecture. Review the active repository and migration status before choosing. A new project that can follow v4 development closely may align with the new foundation; a production project requiring a fixed dependency should use a reviewed tagged version and plan upgrades explicitly.

The current v3.9 package requires PHP 8.4 or newer. The framework is developed around current PHP generations, and the version 4 work is optimized for modern PHP environments. Always use the Composer and Packagist metadata for the exact framework release rather than relying on a general project-page requirement.

Database access is based primarily on Eloquent and its supported connection drivers. Current Charm documentation covers MariaDB, MySQL, PostgreSQL, SQLite, and SQL Server environments. Exact database and server versions depend on the selected Charm, Eloquent, PHP, and driver versions.

Eloquent is a capable and widely understood ORM with expressive models, relationships, query building, casting, pagination, and database support. Charm’s purpose is not to replace strong ecosystem components merely to make the framework appear self-contained. It integrates Eloquent into a different application structure and adds Charm-specific conventions where they improve recurring business-application work.

Twig provides a mature and expressive presentation layer with inheritance, includes, macros, filters, escaping, and a strong separation between templates and application logic. Charm uses Twig for server-rendered applications and websites while remaining suitable as an API backend for JavaScript or other frontends.

Controller actions can declare routes through PHP attributes, including the HTTP method, path, route name, and relevant filters. This keeps request handling close to the code that owns it while the framework performs route discovery, matching, parameter handling, and dispatch.

Yes. Controllers can return structured JSON responses, files, redirects, rendered views, or other output types through the same application model. Authentication tokens, request access, HTTP integrations, filtering, pagination, validation, queues, and events support common API and backend requirements.

Charm includes integrated session-based authentication and token capabilities for web and API use cases. The current Guard system covers login and logout behavior, remembered sessions, route protection, password handling, throttling, and related authentication work. Applications remain responsible for designing their authorization model, roles, permissions, security policies, and risk-appropriate controls.

Scheduled jobs are defined as application classes and executed through Charm’s scheduling system from a recurring system cron or timer. Longer-running or deferred tasks can be added to named, priority-aware queues and processed outside the user-facing request cycle.

Charm Wireframe is the standard starting structure for a Charm application. It provides the project directories, entry points, configuration layout, example web-server files, Composer setup, Bob integration, and the application space where controllers, models, views, routes, jobs, migrations, and modules are built.

Bob is the Charm command-line toolkit. It can create a new project from Charm Wireframe, start a local PHP development server, dispatch application console commands, update itself, and provide a consistent entry point for framework and project operations.

Yes. Modularity is a central architectural principle. Reusable capabilities can package their own behavior and integrate with the framework and application without placing all code inside one central project namespace. The exact public module and package conventions are continuing to be consolidated as part of the version 4 foundation and documentation.

Yes. Redis can be used for application caching and supporting high-performance workloads. Current packages support a Redis client, while the native PHP Redis extension can be used where available. Applications should still design expiration, invalidation, failure handling, persistence, and operational monitoring according to their own data and reliability requirements.

A developer who understands modern PHP, Composer, HTTP, MVC, databases, and basic Linux or web-server operation should be able to follow Charm’s architecture. It is not positioned primarily as a teaching framework for somebody encountering PHP for the first time. Its conventions are designed around professional application development, and the documentation is still expanding toward the complete v4 release.

No. Charm has a much smaller public ecosystem and contributor base. It compensates through a focused core, selected mature dependencies, direct Neoground stewardship, and daily use across Neoground systems. Projects that require a large marketplace of third-party bundles, extensive community training material, or broadly available framework specialists should account for that difference during technology selection.

Standard Composer packages can generally be added like they can in other PHP applications, subject to their PHP requirements, dependencies, initialization model, and compatibility. A package does not need a Charm-specific wrapper unless tighter configuration, lifecycle, module, or application integration is useful.

Pin the current dependency, review the framework changelog and package requirements, preserve application configuration, run automated and application-specific tests, inspect database migrations, and deploy through a controlled environment. Version 4 is a breaking major release and should be treated as an application migration rather than an unattended Composer update.

Use the GitHub issue tracker for reproducible framework defects. Include the exact Charm and PHP versions, operating environment, relevant configuration, minimal reproduction, expected result, actual result, logs, and stack traces needed to investigate the problem. Remove credentials, tokens, personal data, internal source code, and sensitive infrastructure details before publishing diagnostic material.

Useful contributions include focused bug fixes, regression tests, PHP-version compatibility work, documentation, examples, performance analysis, migration notes, security observations, and improvements to the core, wireframe, or Bob toolkit. Discuss large architectural changes before implementing them so they remain compatible with Charm’s compact-core philosophy and the direction of version 4.

Charm is released under the MIT License. Applications must also respect the separate licenses of Twig, Eloquent and Illuminate components, Symfony packages, Monolog, Guzzle, Flysystem, Redis clients, development tools, and any other dependencies they include.