CodeIgniter Database Configuration

Before any Model or Query Builder call can reach a real table, CodeIgniter needs to know which database to connect to. That connection information lives in one config file, app/Config/Database.php — but, as you'll see below, the values that actually get used at runtime are best kept out of that file entirely and supplied through an environment file instead.

1. The app/Config/Database.php File

When you generate a new CodeIgniter 4 project (covered on the Installation & Setup page), it ships with a Database config class containing a default connection group — an associative array describing how to reach your database server:

<?php

namespace Config;

use CodeIgniter\Database\Config;

class Database extends Config
{
    public $default = [
        'DSN'      => '',
        'hostname' => 'localhost',
        'username' => '',
        'password' => '',
        'database' => '',
        'DBDriver' => 'MySQLi',
        // ...additional tuning options (port, charset, etc.)
    ];
}

hostname, username, password, and database are the four values every developer recognizes from any PHP/MySQL project. DBDriver tells CodeIgniter which database engine driver to use — MySQLi for MySQL/MariaDB, with Postgre, SQLite3, and SQLSRV also supported out of the box.

2. Overriding Values with .env

Leaving real credentials hard-coded directly in Database.php is a problem the moment that file is committed to version control — anyone with repository access (or anyone who finds an old public commit) gets your production database password. CodeIgniter's answer is the .env file at your project root: any setting placed there overrides the matching config property automatically, and .env is excluded from Git by default via .gitignore.

The mapping uses dot notation that mirrors the nested config structure: database.default.hostname means "the Database config class, its $default array, the hostname key."

database.default.hostname = localhost
database.default.database = my_app_db
database.default.username = db_user
database.default.password = a-strong-secret-password
database.default.DBDriver = MySQLi

With these lines present, CodeIgniter reads them at boot time and uses them in place of whatever is written in Database.php — you never have to touch or redeploy the config class itself just because a password rotated.

3. Why Credentials Belong in .env, Not in Code

Keeping secrets in .env instead of hard-coded in a tracked PHP file solves several problems at once:

4. Running Migrations with Spark

Once the connection itself is configured, you still need tables to query. CodeIgniter's Migrations feature lets you define your schema changes as version-controlled PHP classes rather than manually running SQL against a server. Migrations are run through spark, the same command-line tool introduced on the Installation & Setup page for tasks like serving the app locally.

php spark migrate

Running that command applies every migration file in app/Database/Migrations/ that hasn't been run yet, in order, tracking which ones have already executed so re-running the command is always safe.

5. Creating a Migration Class

New migration files are scaffolded with another spark command, which generates a timestamped, empty migration class for you to fill in:

php spark make:migration CreateArticles

This generates a class inside app/Database/Migrations/ extending CodeIgniter's base Migration class, with empty up() and down() methods for you to describe "apply this change" and "reverse this change" respectively — for example, creating the articles table in up() and dropping it again in down(). Each migration becomes a permanent, ordered, version-controlled record of how your schema evolved, which every developer and every environment can replay identically by running php spark migrate.