> ## Documentation Index
> Fetch the complete documentation index at: https://docs.instapods.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Worker Pods

> Run a bot, scraper, queue consumer or scheduled job on a pod with no public URL.

Not everything you deploy is a website. A Telegram bot, a Discord bot, a queue consumer, a scraper or a cron-driven script has no web server and nothing to serve - but on a normal pod, InstaPods still gives it a public URL, points nginx at it, and issues a certificate. Nothing is listening, so every request comes back as an error, and the platform's health checks flag the pod as broken.

A **worker pod** is the answer. It's an ordinary pod in every way except one: it has no public ingress at all.

## What changes

| | Web pod (default) | Worker pod |
| - | - | - |
| Public URL | `my-app.nbg1-1.instapods.app` | none |
| nginx vhost and TLS certificate | yes | no |
| DNS record | yes | no |
| Health checks against the URL | yes | no |
| SSH, Web Terminal, Web IDE, files, logs | yes | yes |
| Databases and managed services | yes | yes |
| Backups | yes | yes |

Everything you use to build and operate the pod still works. What goes away is only the front door.

> [!NOTE]
>
> A worker pod has no address to visit, so a browser pointed at its old URL returns "no such host" rather than a misleading `502`. That is the correct answer: the pod is running, it just isn't a website.

## Converting a pod

The switch is reversible, and you can flip it at any time.

**Dashboard**

Open the pod, go to the **Settings** tab, and use the **Pod type** card. Click **Convert to worker** (or **Convert to web pod** to go back).

Switching to a worker removes the pod's public URL, its nginx vhost and its certificate. Switching back regenerates the URL and re-provisions ingress - if the pod is stopped, that happens the next time you start it.

**API**

```bash theme={null}
# Convert to a background worker
curl -X POST https://app.instapods.com/api/pods/my-bot/kind \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"kind": "worker"}'

# Convert back to a website
curl -X POST https://app.instapods.com/api/pods/my-bot/kind \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"kind": ""}'
```

`kind` accepts `"worker"` or `""` (a normal web pod). Converting to the state the pod is already in is a no-op.

> [!WARNING]
>
> Converting a web pod to a worker **drops its domain**. Converting back issues a fresh per-host domain - it may not be the same name you had before, and any custom domain will need to be re-pointed. Don't flip a pod that people are visiting.

## Running your code

A worker pod runs the same start command as any other pod. Point it at your long-running process instead of a web server:

```bash theme={null}
# Deploy your code as usual
instapods deploy my-bot

# Watch it run
instapods logs my-bot -n 200
```

For a Git-deployed worker, set a **Custom Start Command** on the pod's Git tab (for example `node bot.js` or `python -m worker`) so the deploy knows what to run.

> [!TIP]
>
> A worker that only needs to run on a schedule doesn't need to stay resident. Use `cron` inside the pod (via the Web Terminal or SSH) and keep the pod on the Launch plan.

## 1-Click Apps

The pod-type switch isn't offered on 1-Click App pods. Those apps ship a web interface as the whole point of the app, so taking the URL away would leave you no way to use them.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.