earmsby's avatar

Failed deployment

I'm trying to deploy some very minor changes on a Forge site that I've deployed to at least 50 times over the past year or two. Today when I tried to deploy these couple of changes, I got this error"

Tunnel exited with a non-zero code [1].

Error output:
Mon Feb 23 05:40:20 PM UTC 2026

Any suggestions on how to figure out what the problem might be?

0 likes
5 replies
LaryAI's avatar
Level 58

Certainly! Here’s a step-by-step approach to troubleshoot and resolve the “Tunnel exited with a non-zero code [1]” error during your Forge deployment:


1. Review Recent Changes

Even though you mention only minor changes, double-check if you’ve altered anything related to deployment scripts, environment variables, or SSH configurations.


2. Check Forge Deployment Logs

Go to your Forge dashboard → Select your site → Deployments tab. Click on “View Log” for the failed deployment. The log usually contains more details right before the tunnel error.


3. SSH Into The Server

Try logging in to the server manually using SSH:

ssh forge@your-server-ip

If you’re unable to connect, the issue might be with your SSH key, the server’s status, or network/firewall rules.


4. Inspect Server Disk Space & Status

Sometimes deployments fail because the server is out of disk space or resources. Once SSH'ed in, run:

df -h
free -m

Make sure there’s enough disk space and memory left.


5. Review Deployment Hooks

Check your deployment script/hooks in Forge for any commands that may exit with a non-zero code or require input (which isn’t available during an automated deploy process). Common issues can be missed environment variables, breaking shell commands, or failed Composer/NPM steps. For example, make sure none of your deployment commands fail:

cd /home/forge/your-site.com
git pull origin main
composer install --no-interaction --prefer-dist --optimize-autoloader
php artisan migrate --force
npm run production

If any of those fail, the deployment exits with a non-zero code.


6. Check For Scheduled Downtime Or Outages

Ensure there are no hosting outages or network issues:

  • Forge Status
  • Hosting Provider (DigitalOcean, Linode, etc.) Status page

7. Restart Forge Daemon (if applicable)

Sometimes restarting the Forge daemon or the server can help clear issues:

sudo service forge restart
sudo reboot

8. Re-deploy Manually

After taking the above steps, try deploying again from Forge or manually trigger a deployment to see if the error persists.


Summary

If after these steps, your Forge deployment still fails:

  • Paste the full deployment log output here for more context.
  • Double-check any recent changes to deployment scripts or environment variables.
  • Ensure all dependencies (Node, Composer, etc.) are installed and working correctly.

Typical Deployment Script (for reference):

cd /home/forge/your-site.com
git pull origin main
composer install --no-interaction --prefer-dist --optimize-autoloader
php artisan migrate --force
npm install
npm run production

Remove or comment out commands one by one to narrow down the culprit.


Let me know the output of your deployment logs or if you see any specific errors after running these checks!

earmsby's avatar
  1. There was one small change I had recently made to the deployment script: $FORGE_PHP artisan queue:restart. I commented that out and tried to rerun the deployment. It failed again.

  2. The log for the failed deployments only shows this:

Mon Feb 23 05:57:31 PM UTC 2026
=> Deployment failed: An unexpected error occurred during deployment.
  1. I am able to SSH to the server.
  2. I ran the commands to check disk space and memory and they do not seem to be a problem. This is quite a small application that only a few people are using for testing right now.
  3. Here is my current deployment script:
cd /home/forge/mysite.on-forge.com

git pull origin $FORGE_SITE_BRANCH
$FORGE_COMPOSER install --no-dev --no-interaction --prefer-dist --optimize-autoloader

# Prevent concurrent php-fpm reloads...
touch /tmp/fpmlock 2>/dev/null || true
( flock -w 10 9 || exit 1
    echo 'Reloading PHP FPM...'; sudo -S service $FORGE_PHP_FPM reload ) 9</tmp/fpmlock

npm ci && npm run build

This is the same script that has been working fine for months.

  1. The hosting from Vultr. There no outages that I can detect. (And the front end of the app is working fine)
  2. I'm not sure I understand what #7 involves or does.
  3. I have re-run the deployment several times in Forge. How would I attempt to deploy it manually?
Willis1776's avatar

I'm running into the exact same issue. I can successfully SSH into the server. Everything looks good with the disk and memory. Manually running the commands also works. Nothing has been changed with the deployment script for quite a while.

earmsby's avatar

Ok, weird.

I had an older migration that had added fields but failed for some reason a while back. After creating other migrations, I couldn't run them because this older migration would try to run, find that the fields were already created and then fail, blocking the newer migrations from running. So, I simply deleted the file, figuring it would be marked as a deleted file in my next commit. Instead, the commit that I was trying to deploy labelled my deleted file as having renamed to one of the newer migrations I had created after deleting it. I didn't think that would cause the deployment to fail.

But just as a test, I just added a random comment to the migration that was committed as a renamed file instead of a new file. Then I committed that edited migration. Ran the deployment again and this time it ran without a hitch.

Now, I have no idea if that solved the issue or if there was something else going on with Forge or Vultr. But... my last real changes (not just the added comment) were deployed. So, who knows.

earmsby's avatar

Aha!

I had reached out to support at Forge. Many hours later, I got this:

We had a brief platform issue earlier that was affecting some deployments on Forge. It was resolved shortly after, so when you pushed that small change and retried, the underlying issue had already been fixed on our side.

Your edit likely wasn’t the real cause of it starting to work again, just good timing.

Really appreciate you following up, and glad everything is deploying normally now. If you see anything odd again, just let us know.

That makes a lot more sense!

Please or to participate in this conversation.