DEV Community

Cover image for What I Check Before Deploying a Website to Production
Caelora
Caelora

Posted on

What I Check Before Deploying a Website to Production

#automation #kubernetes #devops #programming

What I Check Before Deploying a Website to Production

Deploying a website can feel like the finish line.

The code works.
The pages look right.
The buttons respond.
The tests are passing.

Then you deploy it and discover that something important was missed.

Maybe an environment variable wasn't configured. Maybe the production database is using the wrong connection. Maybe a redirect is broken. Or maybe the website works perfectly on your machine but behaves differently on the server.

Over time, I've found that a simple pre-deployment checklist can prevent a lot of unnecessary problems.

Here are some of the things worth checking before pushing a website into production.

1. Check Environment Variables

Never assume the production environment is identical to your local machine.

Things like these should be checked before deployment:

DATABASE_URL
API_KEY
APP_URL
NODE_ENV
SECRET_KEY
Enter fullscreen mode Exit fullscreen mode

Make sure production values are actually configured and that sensitive credentials aren't accidentally committed to Git.

A .env file sitting inside a repository is an easy mistake to make.

Before committing, check:

git status
git diff
Enter fullscreen mode Exit fullscreen mode

It's also worth reviewing .gitignore and making sure environment files are excluded when appropriate.

2. Test the Production Build

A development environment can hide problems.

For example, a JavaScript application may work perfectly with:

npm run dev
Enter fullscreen mode Exit fullscreen mode

but fail during the production build.

Run the actual build process locally:

npm run build
Enter fullscreen mode Exit fullscreen mode

Then test the generated application as close to the production environment as possible.

This can reveal issues involving:

  • Missing dependencies
  • Invalid imports
  • Environment variables
  • Build configuration
  • Case-sensitive file paths
  • Unused or incompatible packages

Finding these problems before deployment is much easier than finding them from a user's report.

3. Check Database Changes

Database migrations deserve extra attention.

If the application requires a new column, table, index, or constraint, make sure the migration is included in the deployment process.

For example:

Application v1
    ↓
Database v1

Application v2
    ↓
Database v2
Enter fullscreen mode Exit fullscreen mode

Deploying the new application without applying the corresponding database changes can cause unexpected errors.

It's also important to think about backwards compatibility.

During a deployment, there may be a short period where old application code and new database structures interact.

A migration strategy should account for that.

4. Don't Forget Error Handling

Users shouldn't see raw exceptions or database errors.

Instead of exposing something like:

SQLSTATE[HY000]: General error...
Enter fullscreen mode Exit fullscreen mode

the application should provide a useful response while logging the technical details internally.

For example:

Something went wrong.

Please try again in a few moments.
Enter fullscreen mode Exit fullscreen mode

At the same time, developers should still have enough information in the logs to diagnose the actual problem.

Good error handling has two audiences:

Users need clarity.

Developers need details.

Those don't have to be the same message.

5. Check Logs

A deployment isn't finished just because the server says it succeeded.

Check the logs afterward.

Depending on your stack, that could mean looking at:

docker logs
Enter fullscreen mode Exit fullscreen mode

or:

journalctl
Enter fullscreen mode Exit fullscreen mode

or application-specific logs.

Look for:

  • Repeated errors
  • Database connection failures
  • Authentication problems
  • Missing environment variables
  • Timeout errors
  • Unexpected HTTP status codes

A successful deployment pipeline only tells you that the deployment process completed.

It doesn't necessarily tell you that users are having a good experience.

6. Test Important User Flows

Don't test every tiny detail manually.

Instead, identify the flows that would cause the biggest problems if they stopped working.

For example:

Homepage
   ↓
Login
   ↓
Dashboard
   ↓
Create item
   ↓
Save
   ↓
Logout
Enter fullscreen mode Exit fullscreen mode

For an e-commerce website, that might be:

Product
   ↓
Cart
   ↓
Checkout
   ↓
Payment
   ↓
Confirmation
Enter fullscreen mode Exit fullscreen mode

These critical paths deserve extra attention after deployment.

7. Check HTTPS

Make sure the production website is actually using HTTPS.

Open the website manually and check:

https://example.com
Enter fullscreen mode Exit fullscreen mode

Then test the HTTP version:

http://example.com
Enter fullscreen mode Exit fullscreen mode

If HTTP is supposed to redirect to HTTPS, verify that it actually does.

Also check for mixed-content problems where an HTTPS page attempts to load insecure HTTP resources.

Browsers may block those resources or display security warnings.

8. Check DNS

DNS problems can make a perfectly deployed website appear completely broken.

Before or immediately after deployment, verify:

A record
AAAA record
CNAME
MX records
TXT records
Enter fullscreen mode Exit fullscreen mode

depending on what the project requires.

For example, if you're moving a website to a new server, the web server might be configured correctly while the domain still points to the old IP address.

That's not an application bug.

It's simply a DNS issue.

9. Test From Outside Your Network

Something working on your own computer doesn't necessarily mean it's working globally.

If possible, test the website using:

  • Mobile data
  • Another Wi-Fi connection
  • A different device
  • An external monitoring service

This can expose DNS caching issues, firewall rules, CDN configuration problems, or IP restrictions that aren't visible from your development environment.

10. Check Permissions

File and directory permissions can cause strange production-only problems.

The application may need access to:

uploads/
cache/
storage/
logs/
Enter fullscreen mode Exit fullscreen mode

But giving everything 777 isn't a proper solution.

Instead, understand which user actually runs the application and grant only the permissions it needs.

The principle is simple:

Give the application enough permission to work, but not more than necessary.

This becomes especially important when the application handles uploaded files or user-generated content.

11. Test Backups

Having a backup system is different from having a backup system that actually works.

Before relying on backups, verify that you can restore them.

For a database, a backup might look like:

mysqldump database_name > backup.sql
Enter fullscreen mode Exit fullscreen mode

But the important question isn't whether the file exists.

The important question is:

Can you restore the application from it?

A backup that has never been tested is still an assumption.

12. Check Monitoring

Once the website is live, you need a way to know when something breaks.

At minimum, monitor important things such as:

Uptime
HTTP errors
Server resources
Database availability
Disk usage
Application errors
Enter fullscreen mode Exit fullscreen mode

You don't necessarily need an elaborate monitoring stack for a small project.

Even a simple uptime monitor can be useful.

The goal is to discover problems before users start reporting them.

13. Have a Rollback Plan

This is one of the most overlooked parts of deployment.

Before deploying a significant change, know how you would go back.

For example:

Current version
      ↓
Backup
      ↓
Deploy new version
      ↓
Something breaks
      ↓
Rollback
Enter fullscreen mode Exit fullscreen mode

Without a rollback plan, a small production bug can turn into a long debugging session.

With a rollback plan, you can restore the previous working version first and investigate the problem afterward.

14. Keep the Checklist Small

A deployment checklist doesn't need to contain 100 items.

If it's too complicated, people eventually stop using it.

A small project might only need:

[ ] Production build works
[ ] Environment variables checked
[ ] Database migration completed
[ ] HTTPS working
[ ] Critical user flow tested
[ ] Logs checked
[ ] Backup available
[ ] Rollback available
Enter fullscreen mode Exit fullscreen mode

The exact checklist should depend on the project.

A personal side project doesn't need the same process as a financial application serving millions of users.

Final Thoughts

Deployment is not just the moment when code moves from your computer to a server.

It's a transition from an environment you control completely to an environment where real users, real data, network problems, unexpected traffic, and unexpected behavior become part of the equation.

A short checklist can catch many problems before they become incidents.

The goal isn't to make deployment complicated.

It's to make deployment predictable.

When you know what needs to be checked, you can spend less time worrying about what might have gone wrong and more time building the next thing.

Top comments (0)