Skip to main content
InstaPods gives you three commands that all end with “your app is running the new thing”, and their names do not make the difference obvious. This page maps what you changed to the command that picks it up.

​
Pick a command

instapods pods restart also covers every case above that is already on the pod, since a reboot restarts your app too. It is just the slower way to get there. What it cannot do is upload your local files - that is deploy.
Do not stop your app by killing its process (instapods exec my-app -- pkill -f uvicorn and friends). The app runs under systemd with Restart=on-failure, so it comes straight back, and exec runs as the instapod user, which cannot signal a service. Use instapods pods reload to restart the app service, or instapods pods restart to reboot the whole pod.

​
What each command actually does

​
instapods deploy

Two steps, in order:
  1. File sync. Walks your local directory and uploads only files that differ from what is already on the pod, skipping anything matched by --exclude or by your .gitignore. See Excluded files below.
  2. Reload. Calls POST /api/pods/{name}/reload, which installs dependencies, runs the build for presets that have one, restarts the app service, then checks that the service came back up. For nodejs, python and go it also makes an HTTP request to the app and reports the status code. If the service crashed, the last lines of its log are printed for you.
--no-reload stops after step 1, so files are uploaded and nothing is restarted.

​
instapods pods reload

Step 2 on its own: no file upload. Use it when the files on the pod are already what you want and you just need the app to pick them up along with a dependency install. What gets restarted depends on the preset: If the pod is stopped, reload starts it first.

​
instapods pods restart

Stops and starts the whole container, then waits for it to come back and re-points the proxy at it. Everything inside restarts, including any database service you installed. It does not install dependencies and does not build anything - it just brings the pod back up running whatever is on disk. This is the heavier option. It drops in-flight requests and takes longer than a reload, but it is the only one that picks up changes outside your app directory.

​
--no-build is not the same on every preset

instapods deploy --no-build skips the build step of the reload. Only two presets have one, so on the rest it changes nothing:
On the nodejs preset you rarely need --no-build anyway: InstaPods hashes your source tree after each build and skips the build automatically when nothing changed. That is what build skipped (unchanged) in the deploy output means.

​
Excluded files

instapods deploy skips a file if it matches either of these:
  • One of the --exclude patterns. The default set is node_modules, vendor, .git, .env, __pycache__, .DS_Store, .venv, venv, .next, .instapods-build-hash. Passing --exclude replaces this list, it does not add to it.
  • A pattern in the .gitignore file in the directory you are deploying. This is on by default, and the file is read whether or not the directory is a git repository. Only that one file is read - .gitignore files in subdirectories are not.
Pass --no-gitignore to sync everything except the --exclude patterns.
.env is excluded by default, and most .gitignore files list it too. A local .env file will not be uploaded by instapods deploy. Set those values with instapods env set instead.
If a file you expected to see on the pod is missing, this is almost always why. A build output directory named in .gitignore (dist/, build/, .next/) is skipped for exactly the same reason, which is fine when the pod builds your app itself and a problem when you meant to ship the built files. In that case deploy the build directory directly: