Directory Structure

The default VeltoPHP directory structure is designed to provide a clean and simple foundation for building small to medium-sized applications. It uses the HMVC (Hierarchical Model-View-Controller) pattern, making every module self-contained and easy to maintain.

VeltoPHP encourages modularity — each feature or domain of your application can live in its own module, with its own controllers, models, views, and routes. This makes your codebase more organized, especially as your project grows.

However, just like with any flexible framework, you're free to customize and organize your project in a way that suits your needs. VeltoPHP does not impose strict rules on class locations — as long as your files follow the autoloading convention (PSR-4), everything will work seamlessly.

Whether you're building a quick prototype, a small admin backend, or a scalable community project, VeltoPHP’s structure helps you stay productive without getting in the way.

Once installed, you’ll see a directory structure like this in your code editor:

Project Root Structure

Here is an explanation of each folder and file in VeltoPHP project structure:

app Contains basic config dan middleware application classes.

modules This is the heart of the HMVC (Hierarchical Model-View-Controller) structure. Each module typically contains its own Controllers, Models, Views, Routes, and more — fully self-contained features.

public The web root directory. It contains index.php, CSS, JS, images, and other publicly accessible assets. This is the only folder exposed to the browser.

resources Holds non-public resources like view templates, email templates, localization files, and frontend assets (before compilation, if using a bundler).

storage Used to store compiled templates, logs, cache files, session data and other runtime-generated data.

vendor Automatically generated by Composer. This directory contains all PHP dependencies and VeltoPHP Core and packages required by your project.

.env Environment-specific configuration file. Contains sensitive data like database credentials, app URL, mail configuration, etc. Should not be committed to version control.

.env.example Template of the .env file. Used to show the required environment variables without exposing sensitive data. Developers can copy this to create their own .env.

.gitattributes Defines attributes that Git uses when handling path-specific behavior — e.g., line endings, merge strategies, or export settings.

.gitignore Lists files and directories that Git should ignore (not track). Useful to prevent committing temporary files, logs, or local environment configurations.

composer.json Defines project dependencies, autoload rules, and other meta information for Composer — the PHP dependency manager.

composer.lock Automatically generated by Composer to lock the versions of installed packages. Ensures consistency of dependencies across environments.

LICENSE The open-source license file that defines how the project may be used, modified, and distributed.

readme.md Markdown file that usually contains the project’s introduction, installation instructions, usage guide, and other documentation for developers.

velto This file contains the internal code used for the php velto command-line interface (CLI), such as generators, utilities, and automation scripts.