Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

JimNayzium's avatar

.gitignore Question for /config/app.php Values

My live deployment is via Cloudways. It's as simple as can be. All I do is login and go to my application and click on "Deploy from GIT Repo" and it pulls it over to my live site and works like a charm.

The only issues are, of course I have to have a production .env file that I have in my .gitignore which works just fine.

HOWEVER, I also have different values set in the /config/app.php and no matter how I handle it so far it won't work like I need it to.

I guess it had already been tracked by github so I had to run these terminal commands to get it to stop tracking changes for me in the config/app.php.

git rm --cached config/app.php 
git commit -m "Stop tracking config/add.php"

Then the app.php file was not in my Commit version control in vscode.

But what that does is also remove it from the github repo entirely, so when I go to PULL to my cloudways hosting it always comes over without the app.php file. I then login to my FTP software and upload it manually but it is such an un-elegant solution surely there is a better way to utilize the .gitignore ?

Here are the two lines I have to manually toggle each time in my /config/app.php

Am I missing something?

    // : These 2 files uncommented in LOCAL VERSION
    'url' => env('APP_URL', 'http://local.injurymf.com'),
    'frontend_url' => env('APP_FRONTEND_URL', 'http://localhost:5173'),
    
    // : These 2 files uncommented in PRODUCTION VERSION
    // 'url' => env('APP_URL', 'https://app.injurymf.com'),
    // 'frontend_url' => env('APP_FRONTEND_URL', 'https://fantasymf.com'),

What's odd is the .env file on the Cloudways server got put there initially by me manually, but was always in the gitignore so it was never tracked, and therefore it's not deleted when I PULL from GITHUB in the backend of Cloudways Hosting, but for some reason it does delete the app.php in the config folder, I assume becuase it replaces the entire contents of the config folder.

I guess I could try to put /config* in my .gitignore after getting all the correct files manually on the server? Is this the way to go?

Thanks for the help.

0 likes
7 replies
LaryAI's avatar
Level 58

To handle different configurations for local and production environments without manually toggling values in config/app.php, you can leverage environment variables in your .env file. This way, you can keep your config/app.php file in version control and use different .env files for each environment.

Here's a step-by-step solution:

  1. Use Environment Variables in config/app.php:

    Modify your config/app.php to use environment variables for the URLs. This way, you don't need to comment/uncomment lines based on the environment.

    'url' => env('APP_URL', 'http://local.injurymf.com'),
    'frontend_url' => env('APP_FRONTEND_URL', 'http://localhost:5173'),
    
  2. Set Up Different .env Files:

    • Local Environment: Keep your local .env file with local values.

      APP_URL=http://local.injurymf.com
      APP_FRONTEND_URL=http://localhost:5173
      
    • Production Environment: On your production server, create a .env file with production values. This file should not be in version control.

      APP_URL=https://app.injurymf.com
      APP_FRONTEND_URL=https://fantasymf.com
      
  3. Ensure .env is in .gitignore:

    Make sure your .env file is listed in your .gitignore so it is not tracked by Git.

    /.env
    
  4. Deploying to Cloudways:

    When you deploy to Cloudways, the .env file on the server will not be overwritten because it is not tracked by Git. You only need to ensure that the correct .env file is manually placed on the server once.

  5. Avoid Removing config/app.php from Version Control:

    Keep config/app.php in version control. The environment-specific values should be managed through the .env file, not by modifying config/app.php directly.

By following these steps, you can maintain a clean and efficient deployment process without manually toggling configuration values. This approach leverages Laravel's built-in environment configuration capabilities, making it easier to manage different environments.

1 like
JimNayzium's avatar

Well there you have it! What a wonderfully crafted reply from Larry! #KudosLarry

JimNayzium's avatar

Okay, I think what I missed all along was fundamentally what the app.php file was doing with the .env variables to begin with. Basically the FALL-BACK default values is all I was changing and doing so unneccessarily provided I have set the .env files correctly in each environment (Production vs Development).

So the school of thought is if it is live in production and "falls-back" to the local URL, well that's a problem in the .env file, and should be fixed there, and therefore never altering the config/app.php file, correct?

martinbean's avatar

@jimnayzium You should not be altering the config/app.php file, correct. There’s no need to. It just reads its values from environment variables, or an .env file if there is one present.

So, with that being said, can you not just upload an .env file to your server one time via FTP, containing variables for that particular environment, and then carry on deploying your application as normal?

Snapey's avatar

whats wrong with having a .env file in production ... its exactly what it is there for.

Personally, on a new install I edit it live on the prod machine and exclude it from the repo. What you definately should not do is ignore the config/app.php

JimNayzium's avatar

Thanks everyone! I think I just brain-melted this moment, and got so distracted by the fallback URLs in the app.php file being localhost I just wrongly assumed that they had to be the live URL when that file was pushed to the live server!

I 100% have .env that is different for production and working properly and just shanked the logic of it all. I am glad I posted so I can finally see my error in seeing it all clearly! 😄

Please or to participate in this conversation.