Akaunting is a Laravel application, and almost every behavior you care about on shared hosting is controlled by a single plain-text file named .env sitting in your installation root. Database credentials, the application URL, cache drivers, queue connections, mail transport, and the debug toggle all live there. When Akaunting throws a white screen, loops back to the login page, reports a database connection failure after a migration, or stubbornly ignores a value you just changed, the cause is almost always one of two things: a malformed or stale .env file, or Laravel's compiled configuration cache holding on to old values. Understanding how these two layers interact is what separates a five-minute fix from an afternoon of guessing.

On a managed LiteSpeed/CloudLinux account you cannot restart services, edit php.ini globally, or run the full set of php artisan commands you would use on a VPS. That is fine. Every configuration change Akaunting needs can be made through cPanel Jupiter or DirectAdmin Evolution, the File Manager, phpMyAdmin, a per-directory .user.ini, and the application's own Admin dashboard. The rest of this walkthrough stays strictly inside those tools.

Locating and safely editing the .env file

Akaunting lives wherever you installed it, commonly /home/USERNAME/public_html for a primary-domain install or something like /home/USERNAME/public_html/accounting for a subfolder. The .env file is a hidden dotfile, so in cPanel File Manager you must click Settings in the top-right corner and enable Show Hidden Files (dotfiles). DirectAdmin's File Manager exposes a similar toggle. Before touching anything, right-click the file and choose Copy to create .env.backup. A broken .env is the single most common cause of a fully dead Akaunting install, and a backup turns a disaster into a one-click restore.

Open .env with the editor and treat it like a strict key=value file. Values with spaces or special characters must be wrapped in double quotes, there are no spaces around the equals sign, and the APP_KEY line must never be emptied or Laravel will fail to decrypt sessions. The variables you will realistically change on shared hosting are the database block and the application identity:

APP_NAME="My Company Books"
APP_ENV=production
APP_KEY=base64:do-not-touch-this-value
APP_DEBUG=false
APP_URL=https://books.example.com

DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=user_akauntdb
DB_USERNAME=user_akauntusr
DB_PASSWORD="Str0ng-Pass!"

Two details trip people up constantly. First, DB_HOST on cPanel and DirectAdmin is almost always localhost, not 127.0.0.1; the latter forces a TCP connection that some shared stacks block in favor of the local socket. Second, the database name and username carry your account prefix (for example user_) exactly as shown in cPanel's MySQL Databases page. Copy them from there rather than typing from memory. If Akaunting reports SQLSTATE[HY000] [1045] Access denied, the mismatch is in these three lines or the user was never added to the database under Add User To Database with ALL PRIVILEGES. You can confirm the credentials work by logging into phpMyAdmin with that database user before blaming the application.

After editing, set APP_URL to the exact scheme and host your site uses. A mismatch here is the usual reason assets load over HTTP on an HTTPS site, or redirects bounce to the wrong domain. Save the file and verify the permissions read 600 or 644; never leave .env world-writable.

Clearing stale config and application cache without artisan

Here is the behavior that confuses most Akaunting users on shared hosting: you change a value in .env, reload the site, and nothing happens. Laravel compiles its configuration into bootstrap/cache/config.php for performance, and once that file exists your .env edits are ignored entirely until the cache is rebuilt. On a VPS you would run php artisan config:clear. Without SSH you simply delete the compiled files through File Manager.

Navigate into the Akaunting install, open the bootstrap/cache folder, and delete config.php, routes.php, events.php, and packages.php if present. Do not delete the bootstrap/cache folder itself and do not touch services.php unless it is clearly corrupt. Laravel regenerates these on the next request from live .env and config values. This single action resolves the majority of "my change didn't apply" reports, including stale database credentials, an outdated APP_URL, and mail settings that refuse to update.

The companion folder is storage/framework, which holds cache, sessions, and views subdirectories. If Akaunting shows a blank page after an update, or forms submit but nothing saves, clearing the compiled Blade views helps: delete the contents inside storage/framework/views (the *.php files), not the folder. For session weirdness such as being logged out instantly, clear the files inside storage/framework/sessions. Akaunting also keeps a maintenance and company cache under storage/framework/cache/data; emptying that directory forces a clean rebuild of dashboard widgets and permissions. If Akaunting itself is reachable, the Admin area under Settings → Company and the update flow at Updates will repopulate these automatically. Confirm that storage and bootstrap/cache remain writable at 755 for directories and 644 for files so Laravel can rewrite them.

PHP version, limits, and extensions through the panel

Akaunting's installer, backups, and module imports are memory- and time-hungry, and the default shared PHP limits are often too low. Select your PHP version first. In cPanel Jupiter open MultiPHP Manager, pick the domain, and set it to a supported branch (Akaunting 3.x needs PHP 8.1 or newer). In DirectAdmin Evolution this lives under Account Manager → Select PHP Version. On the same CloudLinux PHP Selector screen you enable extensions; Akaunting requires bcmath, ctype, gd, intl, json, mbstring, openssl, pdo_mysql, tokenizer, xml, and zip. A missing bcmath or intl is a frequent cause of fatal errors during installation.

Raise the runtime limits in the same PHP Selector Options tab, or override them per-directory with a .user.ini file placed in the Akaunting root alongside index.php:

memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 64M
post_max_size = 68M
max_input_vars = 5000

LiteSpeed reads .user.ini but caches it for up to five minutes, so wait before retesting. The max_input_vars bump matters specifically for Akaunting's permission and tax-rate screens, which submit large forms that silently truncate when the limit is too low. If you need an ad-hoc upload ceiling for a bank-statement import, you may instead add php_value upload_max_filesize 64M to .htaccess, though .user.ini is the cleaner home for PHP directives on a LiteSpeed account.

Debug mode, error logs, and controlled troubleshooting

When you need to see why a page breaks, set APP_DEBUG=true in .env, delete bootstrap/cache/config.php so the change takes effect, and reload the failing page. Laravel then prints a full stack trace naming the file, line, and exception. This is diagnostic only: leaving debug enabled on a live accounting application exposes database credentials and file paths in error output, so switch it back to false and clear the config cache again the moment you have your answer.

The quieter and safer source of truth is the log at storage/logs/laravel.log. Open it in File Manager, scroll to the bottom for the most recent entries, and read the timestamped exception. Database access errors, missing extensions, and permission problems all surface here with enough detail to act on. Your account's PHP error_log (visible in cPanel Errors or as an error_log file in the directory where the fault occurred) captures fatal errors that happen before Laravel can even boot, such as a syntax slip in .user.ini. Between these two logs you can diagnose nearly every configuration fault without ever needing shell access. The same cache-clearing discipline that applies here mirrors Laravel-wide tuning described in our Statamic performance and caching guide, since both rest on the same compiled-config and OPcache behavior under LiteSpeed. Once your edits are confirmed working, reset APP_DEBUG to false, restore 600 permissions on .env, and delete any .env.backup files you no longer need so credentials are not left sitting in the web root.