Keeping it running somewhere else is where deployment starts introducing extra work.

You need a machine, a Python runtime, dependencies, environment variables, logs, a reliable start command, and some way to restart the application when things go wrong. If it's a web application, you also need networking and HTTPS.

Traditionally, that often means renting a VPS and configuring everything yourself.

But the underlying deployment process can be much simpler:

GitHub repository → build environment → dependencies → start command → running application

In this guide, we'll walk through what a Python project needs to be deployable and how to take it from GitHub to a running workload.

1. Start with a deployable Python project

A deployment platform needs to know two fundamental things:

1. What dependencies does your application require?

2. What command starts it?

A simple Python project might look like:

my-python-app/
├── app.py
├── requirements.txt
└── README.md

For example, app.py could contain a small Flask application:

from flask import Flask

app = Flask(__name__)

@app.get("/")
def home():
    return {"status": "running"}

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000)

And requirements.txt might contain:

Flask
gunicorn

That dependency file is important because the deployment environment needs a reproducible way to install the packages your application expects.

2. Make sure your dependencies are declared

A common deployment failure is an application relying on packages that happen to exist on the developer's computer.

Your deployment environment won't have those packages unless you declare them.

With a requirements.txt workflow, dependencies can be installed with:

pip install -r requirements.txt

If your project uses another Python dependency-management approach, the same principle applies:

the repository needs to contain enough information to reconstruct the application's environment.

Your laptop shouldn't be part of the deployment specification.

3. Define how the application starts

Installing the code isn't the same thing as running it.

The deployment system eventually needs a command that starts the workload.

For a Flask application using Gunicorn, that might be:

gunicorn app:app --bind 0.0.0.0:8000

A background worker could instead be something as simple as:

python worker.py

And a Discord bot might run with:

python bot.py

This distinction matters because not every Python deployment is a web application.

Some workloads listen for HTTP traffic.

Others need to remain alive continuously while processing jobs, consuming queues, responding to events, or maintaining external connections.

A deployment platform needs to handle both models appropriately.

4. Push the project to GitHub

Once the application contains its source code, dependency declaration, and startup behavior, push it to a GitHub repository.

GitHub now becomes more than source control.

It becomes the source from which a deployment can be reproduced.

A deployment should also be associated with the specific Git revision being deployed.

That's useful when debugging because:

"Production is broken"

is much less actionable than:

"Commit abc123 failed during dependency installation."

Knowing exactly which revision produced a deployment makes logs and deployment history considerably more useful.

5. Configure environment variables

Applications frequently need configuration that shouldn't be hardcoded into the repository.

Examples include:

DATABASE_URL
API_KEY
DISCORD_TOKEN
SECRET_KEY

These should be configured as environment variables in the deployment environment rather than committed directly to GitHub.

Your Python application can then read them:

import os

database_url = os.environ.get("DATABASE_URL")

This keeps configuration separate from source code and allows different values between development and production.

And, importantly:

don't commit secrets to your Git repository.

6. Build the deployment environment

Once a deployment begins, the platform needs to create an environment capable of running the application.

Conceptually, that means:

Retrieve source
      ↓
Select revision
      ↓
Prepare Python environment
      ↓
Install dependencies
      ↓
Apply configuration
      ↓
Start application

Containers are particularly useful here because they provide a predictable runtime boundary around the application.

But containers aren't the entire deployment system.

The platform still has to manage things such as:

• resource limits

• lifecycle state

• logs

• failures

• restarts

• networking

• deployment history

• worker capacity

Getting a Python process to start is only one part of keeping it running.

7. Watch the deployment logs

Logs are one of the first places to look when a Python deployment fails.

Typical failures include:

ModuleNotFoundError

A dependency may be missing.

ImportError

The installed package version may not match what the application expects.

Permission denied

The application may be attempting to access something unavailable in its runtime environment.

Or the process may simply exit because the startup command points at the wrong module.

Deployment logs should expose enough of the build and startup process to identify these failures without requiring access to the underlying server.

8. Web apps need to listen correctly

This is a particularly common deployment issue.

A local development server might bind to:

127.0.0.1

Inside a deployed environment, that can prevent external traffic from reaching it.

Web applications generally need to listen on:

0.0.0.0

and on the port expected by the deployment environment.

For example:

gunicorn app:app --bind 0.0.0.0:8000

Once the application is listening correctly, an ingress or reverse-proxy layer can route public traffic to the running workload and terminate HTTPS.

9. Persistent Python workloads are different

Not every Python application needs a URL.

Consider:

while True:
    process_jobs()

Or a Discord bot maintaining a persistent connection.

Or a queue consumer waiting for work.

These processes need to stay alive, but exposing an HTTP endpoint may make no sense.

That's why it's useful to think about deployment in terms of workloads, rather than assuming every deployment is a website.

Web applications require ingress.

Persistent workers require reliable process lifecycle management.

Both require logs, resources, configuration, deployment history, and recovery.

10. Deploying through Deploy Hatch

This is the workflow we're building Deploy Hatch around.

Instead of manually provisioning a server and configuring the deployment stack, the workflow starts with your GitHub repository.

You connect GitHub, select the repository you want to deploy, configure the workload, provide any required environment variables, and start the deployment.

Behind that simple workflow, Deploy Hatch handles the infrastructure necessary to turn the repository into a running containerized workload.

You can then inspect deployment logs and manage the running application without SSHing into a server.

For supported web applications, the deployment can also be routed through HTTPS ingress.

Persistent workloads such as bots and background workers can remain running without needing a public web endpoint.

If you want to try the Python deployment workflow, the Python deployment documentation is available at:

https://deployhatch.com/docs/deploy-python

What actually matters in a Python deployment?

The deployment platform can automate a lot, but the application still needs to clearly communicate its requirements.

At minimum, think about:

• dependencies

• startup command

• environment variables

• listening address and port for web applications

• required runtime resources

• external services the application depends on

Once those pieces are explicit, deployment becomes much more reproducible.

And reproducibility is really the goal.

You don't want an application that runs because someone manually configured the right combination of packages on a particular server six months ago.

You want:

Code + configuration + revision
              ↓
      reproducible deployment
              ↓
        running workload

That's a much easier system to understand, debug, and rebuild when something inevitably goes wrong.

You connect a repository, configure a few settings, and click:

Deploy.

A few moments later, hopefully, your application is running.

But that button hides a surprising amount of infrastructure.

Some system has to decide exactly which code to deploy. A machine needs to accept the work. Dependencies have to be installed. Builds need to execute. A runtime needs to be created. Secrets need to reach the application without becoming part of its source code. Logs have to go somewhere. Network traffic needs to find the correct process.

And when something fails halfway through, the system needs to know what actually happened.

While building Deploy Hatch, I've spent a lot of time working on everything that happens on the other side of that button.

So let's follow a deployment all the way through.

Deployment starts with intent, not a container

Suppose you've connected a GitHub repository containing a Node.js application.

You click Deploy.

The first thing a deployment platform should not do is immediately start throwing Docker commands at some server.

First, it needs to record what you're asking it to do.

Conceptually, a deployment request contains information such as:

Project
Repository
Branch
Git revision
Runtime configuration
Build command
Start command
Environment configuration
Resource limits
Deployment status

That distinction matters.

The deployment record represents the desired operation.

The container is eventually one implementation of that operation.

Keeping those concepts separate makes it possible to track deployment history, retries, failures, cancellation, scheduling and recovery without treating Docker itself as the source of truth.

Step 1: Identify exactly what should run

"The code from GitHub" isn't precise enough.

Repositories change.

Branches move.

Someone can push another commit while a deployment is happening.

A deployment should therefore be associated with a specific Git revision whenever possible.

Imagine this history:

main

A ── B ── C ── D
              ↑
           deploy

If commit D is what triggered the deployment, that's the revision the platform should expect to run.

This gives us a useful question later:

What exact code is running in production?

Instead of:

Probably whatever was on main when we deployed.

That becomes especially important when debugging a regression or comparing deployment history.

Step 2: Put the deployment into a queue

Once the deployment exists, something needs to execute it.

Immediately assigning work directly from a web request to a server creates unnecessary coupling between the control plane and the infrastructure doing the work.

A queue creates a boundary.

Conceptually:

Developer
    │
    ▼
Control Plane
    │
    ▼
Deployment Queue
    │
    ▼
Worker

The control plane can say:

This deployment needs to happen.

A worker can independently say:

I have capacity to perform it.

That separation becomes increasingly useful as infrastructure grows.

Step 3: A worker claims the deployment

A deployment worker is a machine responsible for executing deployment jobs.

But not every worker should blindly accept every job.

The platform needs to consider capacity.

A worker may already be running several workloads. It has finite CPU, memory and container capacity.

So before accepting additional work, the system needs to understand its own resources.

Conceptually:

Worker

CPU capacity
Memory capacity
Running containers
Reserved resources
Scheduling enabled?
Health status

A healthy worker with sufficient capacity can claim the deployment.

That claim is important because two workers should not independently decide to execute the same deployment.

Once claimed, the worker becomes responsible for moving that deployment through its lifecycle.

Step 4: Retrieve the repository

Now we finally need the application code.

The worker retrieves the appropriate repository and revision from GitHub.

Conceptually:

GitHub
   │
   │ repository + revision
   ▼
Worker workspace

The revision matters here again.

If the deployment expects commit:

abc123

the source used for the build should correspond to:

abc123

rather than silently deploying some newer revision that appeared afterward.

A deployment system that can't tell you what source it actually executed makes production debugging unnecessarily difficult.

Step 5: Determine how to build the application

Different repositories need different preparation.

A Node.js application might have:

package.json
package-lock.json

A Python application might have:

requirements.txt

Some projects require a build step.

Others don't.

For example:

npm install
npm run build
npm start

versus:

npm install
npm start

The deployment system needs enough information—either detected or explicitly configured—to determine how the application should be prepared and started.

Detection can make the common case convenient.

Configuration provides an escape hatch when the common case is wrong.

That balance matters.

"Magic" deployment behavior is pleasant until the magic guesses incorrectly.

Step 6: Execute the build

Builds are effectively running someone else's repository code on infrastructure you operate.

That's a significant trust boundary.

A build might consume too much memory.

It might consume CPU indefinitely.

It might spawn excessive processes.

It might hang.

So production deployment infrastructure shouldn't treat build execution as unrestricted shell access.

Builds need boundaries.

For example:

CPU limit
Memory limit
PID/process limit
Timeout
Filesystem restrictions
Privilege restrictions

This isn't only about malicious code.

A perfectly innocent build can accidentally exhaust a machine.

One runaway deployment shouldn't prevent unrelated applications from running.

That's one of the less visible parts of building deployment infrastructure: resource management is part of reliability.

Step 7: Stream the logs

Meanwhile, the developer needs to know what's happening.

A deployment that displays:

Building...

for five minutes and eventually says:

Failed

isn't particularly useful.

The output from the underlying operation needs to make its way back to the user.

For example:

Installing dependencies...

added 143 packages

Running build...

> npm run build

Build completed successfully.

Starting application...

And when something breaks:

npm ERR! Missing script: "build"

That message is dramatically more useful than:

Deployment failed.

Logs aren't merely a convenience.

They're part of the interface between infrastructure and the developer trying to understand it.

Step 8: Create the runtime container

Once preparation succeeds, the application needs somewhere to run.

Deploy Hatch uses isolated Docker containers for workloads.

Conceptually:

Worker
┌─────────────────────────────┐
│                             │
│   ┌─────────────────────┐   │
│   │ Application         │   │
│   │                     │   │
│   │ Node.js / Python    │   │
│   │ dependencies        │   │
│   │ application code    │   │
│   └─────────────────────┘   │
│          Container          │
│                             │
└─────────────────────────────┘

The container provides a defined runtime boundary for the workload.

This also gives the platform a consistent lifecycle:

create
start
stop
restart
inspect
remove

But containerization isn't a complete security model by itself.

Production workloads still need sensible resource, privilege and filesystem restrictions around that container.

Step 9: Inject configuration

Applications frequently need values that should not live in GitHub.

For example:

DATABASE_URL
DISCORD_TOKEN
API_KEY
JWT_SECRET

The application reads those values through its environment:

const databaseUrl = process.env.DATABASE_URL;

The deployment system provides them at runtime.

This keeps environment-specific configuration separate from the repository and avoids requiring developers to commit production secrets into source control.

The principle is straightforward:

GitHub → application code

Deployment configuration → environment/secrets

The application receives both when it runs.

Step 10: Start the application

Now the workload can finally start.

For a Node.js application, that might ultimately execute:

npm start

For another project:

node dist/server.js

Or for Python:

python bot.py

At this point, the process existing isn't enough.

The platform needs to determine whether the runtime actually started successfully and persist the resulting deployment state.

A deployment lifecycle might move through states resembling:

queued
   ↓
building
   ↓
starting
   ↓
running

And when things go wrong:

building → failed

starting → failed

running → stopped

Terminal states need to be recorded accurately because deployment history becomes operational evidence later.

Step 11: Route traffic to web applications

A Discord bot or background worker may already be finished from an infrastructure perspective.

It simply needs to stay running.

A web application has another requirement:

traffic needs to reach it.

The container might be listening internally on a port such as:

3000

But users shouldn't have to know the worker's IP address and container port.

Instead, traffic goes through an ingress layer.

Deploy Hatch's current model looks conceptually like:

Browser
   │
   │ HTTPS
   ▼
Public hostname
   │
   ▼
Ingress / reverse proxy
   │
   ▼
Worker
   │
   ▼
Application container

The developer gets a public HTTPS application URL while the internal container remains behind the platform's routing layer.

That is why something as simple-looking as:

https://your-app.example

actually represents several pieces of infrastructure working together.

Step 12: Persist what happened

Once the application is running, the deployment system needs to remember more than:

status = running

Useful deployment history can answer questions such as:

Which repository was deployed?

Which Git revision?

When did the deployment start?

When did it finish?

Which worker executed it?

Did it succeed or fail?

What logs were produced?

What runtime is associated with it?

This becomes particularly useful after multiple deployments.

Deployment #21  running   commit d91ab3
Deployment #20  failed    commit 82ef11
Deployment #19  stopped   commit 613caa

Now production state can be connected back to source history.

But deployment isn't finished when the button turns green

This is one of the biggest lessons from building the infrastructure behind Deploy Hatch.

Getting a container to start is the easy part.

Keeping the system truthful afterward is harder.

Machines restart.

Processes crash.

Network state changes.

A worker service gets upgraded.

Containers may survive while the process responsible for tracking them restarts.

That creates an important recovery problem.

Suppose:

Worker service → restarts

Application container → still running

Should the application be killed simply because the worker restarted?

Ideally, no.

The worker needs to inspect the existing runtime state and reconcile it with what the control plane believes should exist.

Conceptually:

Worker starts
    │
    ▼
Inspect existing containers
    │
    ▼
Match them to deployments
    │
    ▼
Adopt valid workloads
    │
    ▼
Reconcile routing/state

This allows infrastructure maintenance without unnecessarily destroying healthy customer workloads.

Recovery is part of deployment infrastructure too.

The control plane and runtime can disagree

Distributed systems eventually encounter disagreement.

The database might say:

running

while the container no longer exists.

Or a container might still be running while a worker temporarily disappeared.

A reliable platform can't assume any individual source of state is permanently correct.

It has to reconcile them.

That means asking questions like:

What does the control plane expect?

What does the worker report?

What containers actually exist?

Which workloads are healthy?

Which state should be repaired?

This is why deployment platforms eventually become distributed-systems projects rather than sophisticated shell scripts.

What the Deploy button is really doing

So when you click:

Deploy

the real workflow looks much closer to:

GitHub repository
       │
       ▼
Create deployment
       │
       ▼
Record Git revision
       │
       ▼
Queue job
       │
       ▼
Worker claims job
       │
       ▼
Retrieve source
       │
       ▼
Prepare/build application
       │
       ▼
Stream logs
       │
       ▼
Create isolated runtime
       │
       ▼
Inject configuration
       │
       ▼
Start process
       │
       ▼
Persist deployment state
       │
       ├──── Background workload → keep running
       │
       └──── Web workload
                    │
                    ▼
              Configure ingress
                    │
                    ▼
                  HTTPS
                    │
                    ▼
              Running application

And surrounding that entire pipeline are:

resource enforcement
security boundaries
timeouts
cancellation
failure handling
worker health
deployment history
recovery
state reconciliation

That's a lot of machinery hiding behind one button.

Good infrastructure disappears at the right level

Developers shouldn't need to think about every one of these systems every time they ship a project.

But somebody has to.

That's the tradeoff behind developer platforms.

The platform absorbs infrastructure complexity so the application developer can operate at a higher level:

repository
configuration
deploy
logs
running application

without pretending that the underlying infrastructure somehow stopped existing.

Building Deploy Hatch has made the word deploy feel much larger than it used to.

And that's probably a good thing.

Once you understand everything happening after that button is clicked, you start appreciating why making deployment feel boring requires quite a lot of engineering underneath.

If you'd like to see the developer-facing side of that pipeline, Deploy Hatch is currently being built around a simple goal:

connect a GitHub repository and turn it into a running workload without having to manage the underlying server yourself.

https://deployhatch.com

The code is pushed to GitHub. Your dependencies are defined. npm start works.

Now you need to get it running somewhere other people—or other services—can actually reach it.

This is the point where a relatively simple Node.js project can suddenly turn into an infrastructure project.

A traditional deployment might require provisioning a server, configuring SSH, installing Node.js, cloning the repository, managing environment variables, setting up a process manager, configuring a reverse proxy, enabling HTTPS, and figuring out what should happen when the application crashes.

Those are useful skills to understand.

But they aren't necessarily things you should have to manage every time you want to ship an application.

In this guide, we'll look at what a Node.js application actually needs to be deployable and how a GitHub repository can go from source code to a running workload.

What we're deploying

Consider a very small Express application.

const express = require("express");

const app = express();

const port = process.env.PORT || 3000;

app.get("/", (req, res) => {
  res.json({
    status: "running",
    message: "Hello from Node.js!"
  });
});

app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

Its package.json might look like this:

{
  "name": "example-node-app",
  "version": "1.0.0",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "express": "^5.0.0"
  }
}

There isn't much to it.

But there are several details here that become important once the application leaves your computer.

1. Make sure your application has a start command

A deployment platform needs to know how to start your application.

For many Node.js projects, that information already exists in package.json.

For example:

{
  "scripts": {
    "start": "node index.js"
  }
}

Or, if your application needs to be built first:

{
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js"
  }
}

Frameworks may use their own commands:

{
  "scripts": {
    "build": "next build",
    "start": "next start"
  }
}

The important idea is simple:

Your repository should contain a reproducible way to build and start the application.

If running your project requires a series of commands that exist only in your head, deployment becomes much harder.

2. Don't hard-code the port

This is one of the easiest mistakes to make when moving a Node.js application into a hosted environment.

Locally, you might write:

app.listen(3000);

A deployment environment may need to provide the port dynamically.

Instead, read it from the environment:

const port = process.env.PORT || 3000;

app.listen(port);

The fallback keeps local development convenient while allowing the deployment environment to control the production port.

The same principle applies to other configuration.

Your application should get environment-specific values from its environment rather than requiring source-code changes for each deployment.

3. Keep secrets out of GitHub

Suppose your application uses an API key.

Don't do this:

const apiKey = "my-secret-api-key";

And don't commit a production .env file containing credentials to your repository.

Instead:

const apiKey = process.env.API_KEY;

Your deployment environment can then provide API_KEY separately from the source code.

This is useful for:

• API keys

• database connection strings

• authentication secrets

• Discord bot tokens

• webhook secrets

• third-party service credentials

Your GitHub repository contains the application.

Your deployment environment contains its secrets.

Keeping those responsibilities separate makes deployments safer and easier to reproduce.

4. Push the deployable version to GitHub

Once the application is ready, commit it normally:

git add .
git commit -m "Prepare app for deployment"
git push origin main

At this point, GitHub becomes more than source control.

It can also become the source for your deployment.

Instead of manually transferring files to a server, a deployment system can retrieve a specific repository and revision directly from GitHub.

Conceptually, the workflow becomes:

GitHub repository
       ↓
Deployment request
       ↓
Build application
       ↓
Create runtime
       ↓
Start application
       ↓
Expose application

This is the model used by many modern application platforms.

The traditional VPS approach

You can absolutely deploy the application yourself.

A simplified VPS workflow might look something like:

ssh user@server

git clone <repository>
cd <repository>

npm install
npm run build
npm start

But npm start alone isn't enough for a reliable production deployment.

What happens when you disconnect from SSH?

What restarts the application after a crash?

What happens when the machine reboots?

How does traffic reach the application?

Where does HTTPS come from?

How do you inspect previous deployments?

How do you safely update the application?

You can solve those problems yourself.

You might introduce a process manager such as PM2 or systemd, configure Nginx or Caddy, provision TLS certificates, establish deployment scripts, configure firewall rules, and build your own logging and monitoring workflow.

For some projects, that's exactly the right approach.

For others, maintaining all of that infrastructure is unrelated to what you're actually trying to build.

Deploying directly from GitHub instead

Deployment platforms move much of that infrastructure behind an application-level workflow.

This is also the approach we're building with Deploy Hatch.

Instead of provisioning a server for every application, the workflow starts with the repository.

A deployment looks roughly like:

GitHub
   ↓
Deploy Hatch control plane
   ↓
Deployment queue
   ↓
Worker
   ↓
Build/runtime preparation
   ↓
Isolated container
   ↓
Running Node.js application

The developer chooses the repository and deployment configuration.

The platform handles the infrastructure required to turn that source code into a running workload.

Deploying a Node.js repository with Deploy Hatch

The basic workflow is intentionally short.

Connect GitHub

Authenticate with Deploy Hatch and connect your GitHub account.

Select the repository containing your Node.js application.

This allows the deployment system to retrieve the repository and the Git revision being deployed.

Create the project

Create a project for the repository.

The repository provides much of the information needed to understand the application, including files such as:

package.json
package-lock.json

and the scripts defined inside them.

Configure environment variables

Add any values your application expects from process.env.

For example:

DATABASE_URL
API_KEY
JWT_SECRET

These values belong in the deployment configuration rather than being committed to GitHub.

Start the deployment

Deploy the project.

The deployment is queued for a worker, which prepares the workload and starts it inside an isolated container.

During that process, logs provide visibility into what is happening.

Instead of seeing only:

Deployment failed

you want the underlying output that explains why it failed.

For example:

npm ERR! Missing script: "start"

or:

Error: Cannot find module 'express'

Those messages turn deployment failures into problems you can actually debug.

What happens after the application starts?

A successful process isn't automatically a useful web application.

The application also needs a way to receive traffic.

For supported web workloads, Deploy Hatch provides a public application URL and routes HTTPS traffic through its ingress layer to the running container.

The path becomes:

Internet
   ↓
HTTPS
   ↓
Ingress
   ↓
Application container
   ↓
Node.js process

This removes another collection of infrastructure tasks from the individual project.

You don't need to manually configure a reverse proxy just to make a small Node.js application reachable.

Deploying updates

Eventually you'll change the application.

Perhaps you fix a bug:

res.json({
  status: "running",
  version: "2.0"
});

Commit and push the update:

git add .
git commit -m "Update API response"
git push

A new deployment can then run from the updated repository revision.

Tracking the Git revision matters because "the latest code" isn't a particularly useful description when you're debugging production.

You want to know which commit is actually running.

A deployment history tied to repository revisions gives you that visibility.

Web applications aren't the only Node.js workloads

Not every Node.js process needs an HTTP endpoint.

Consider a Discord bot:

const { Client, GatewayIntentBits } = require("discord.js");

const client = new Client({
  intents: [GatewayIntentBits.Guilds]
});

client.once("ready", () => {
  console.log(`Logged in as ${client.user.tag}`);
});

client.login(process.env.DISCORD_TOKEN);

There is no Express server here.

There may be no public website at all.

The important requirement is simply:

keep the process running.

The same applies to many:

• Discord bots

• queue consumers

• background workers

• scheduled processors

• event listeners

• automation services

That's why it's useful to think in terms of deploying workloads, not just websites.

Some applications need public ingress.

Others only need a reliable persistent runtime.

What makes a repository deployment-friendly?

Before deploying a Node.js application, I use a short checklist:

• The application has a clear start command.

• Dependencies are declared in package.json.

• A lockfile is committed when appropriate.

• Secrets come from environment variables.

• Web servers respect the provided PORT.

• Required build commands are reproducible.

• Generated local files aren't required for startup.

• The application writes useful information to stdout/stderr.

• The repository contains the code needed to reproduce the running application.

These practices aren't specific to any one hosting platform.

They make Node.js applications easier to deploy almost anywhere.

Deployment should be boring

There is a lot happening between a Git commit and a production process.

Repository retrieval, dependency installation, builds, runtime configuration, containers, networking, TLS, logging, health management, recovery, and deployment state all have to work together.

Understanding those pieces is valuable.

Having to manually rebuild them for every side project isn't.

The goal of a deployment platform isn't to pretend infrastructure doesn't exist.

It's to provide a reliable abstraction over infrastructure so developers can spend more time working on their applications.

If you have a Node.js repository on GitHub and want to try that workflow, you can deploy it with Deploy Hatch:

https://deployhatch.com/deploy-nodejs

You create the bot, install discord.js, add a few commands, run:

npm start

and everything works.

Then you close your terminal.

The bot goes offline.

At that point, you've discovered something important about Discord bots: they aren't websites that wake up when somebody visits them.

A Discord bot maintains a persistent connection to Discord's gateway. If the process stops running, the bot disappears.

That means putting a Discord bot into production isn't just a programming problem.

It's an infrastructure problem.

In this guide, I'll walk through what a Discord bot actually needs to stay online, how the traditional VPS approach works, and how I'm approaching the problem with Deploy Hatch: GitHub repository → deployment → persistent container.

Why does a Discord bot need 24/7 hosting?

A typical Discord bot establishes a connection to Discord and waits for events.

A minimal discord.js bot might look something like this:

const {
  Client,
  GatewayIntentBits
} = require("discord.js");

const client = new Client({
  intents: [GatewayIntentBits.Guilds]
});

client.once("ready", () => {
  console.log(`Logged in as ${client.user.tag}`);
});

client.login(process.env.DISCORD_TOKEN);

There isn't a webpage here.

The application starts, connects to Discord, and then keeps running.

When somebody invokes a command, joins a server, sends an interaction, or triggers another event you've subscribed to, the existing process receives it.

Kill that process and the connection disappears.

That's why running your bot from your development computer isn't a great production strategy.

Your bot's uptime becomes dependent on your computer's uptime.

Sleep your PC?

Bot offline.

Restart Windows?

Bot offline.

Lose your internet connection?

Bot offline.

Close the terminal by accident?

You get the idea.

The real goal is therefore not simply:

Run my JavaScript.

It's:

Keep this application running somewhere reliable without requiring my development computer to remain online.

The traditional solution: rent a VPS

One of the most common solutions is a virtual private server.

You rent a small Linux server from a cloud provider and turn it into your bot's new home.

That absolutely works.

But now you're responsible for the server.

A typical deployment might involve connecting over SSH:

ssh user@your-server

Installing Node.js and Git, cloning your repository:

git clone your-repository
cd your-repository
npm install

configuring environment variables, and starting the application:

npm start

Unfortunately, that still isn't enough.

Close your SSH session and you don't want the bot disappearing with it.

So now you introduce something like systemd, PM2, Docker, or another process-management strategy.

For example, with PM2:

npm install -g pm2

pm2 start src/index.js --name my-discord-bot
pm2 save
pm2 startup

Then you need to think about updates.

Maybe your deployment process becomes:

cd my-discord-bot
git pull
npm install
pm2 restart my-discord-bot

And eventually:

Why did the bot crash?

So you SSH back into the machine and inspect logs.

Then:

Why didn't it restart after the server rebooted?

Back into the server.

Then:

Why does the production machine have a different Node version than my development environment?

Back into the server.

None of this means VPS hosting is bad.

A VPS gives you enormous flexibility and control.

But running a Discord bot and administering a Linux server are two different jobs.

I wanted the first one without requiring developers to spend as much time on the second.

What does a Discord bot actually need?

If we remove the VPS itself from the equation, the requirements become much clearer.

A production Discord bot generally needs:

• a persistent runtime

• a reproducible dependency installation

• a defined start command

• secure environment variables

• application and deployment logs

• lifecycle controls

• a way to deploy updates

• isolation from other workloads

• some mechanism for recovering when infrastructure changes or fails

Notice what isn't inherently required:

SSH.

SSH is one way to operate the infrastructure.

It isn't a requirement of the Discord bot.

That's the distinction I've been building around with Deploy Hatch.

Instead of giving the developer a server and saying configure this, the platform can take a repository and turn it into the running workload.

Step 1: Prepare your Discord bot repository

Let's use a simple Node.js Discord bot.

A basic project could look like this:

my-discord-bot/
├── src/
│   └── index.js
├── package.json
├── package-lock.json
└── .gitignore

Your package.json should tell the deployment environment how to start the application.

For example:

{
  "name": "my-discord-bot",
  "version": "1.0.0",
  "scripts": {
    "start": "node src/index.js"
  },
  "dependencies": {
    "discord.js": "^14.0.0"
  }
}

The important part is:

"start": "node src/index.js"

You want the application startup process to be deterministic.

A deployment system shouldn't have to guess which random development command you normally type into your terminal.

Your repository should describe how the application runs.

Step 2: Don't put your Discord token in GitHub

Your bot needs its Discord token to authenticate.

But this:

client.login("MY_SUPER_SECRET_DISCORD_TOKEN");

is a bad idea.

And putting this in a committed .env file isn't much better:

DISCORD_TOKEN=MY_SUPER_SECRET_DISCORD_TOKEN

Your production secrets shouldn't live in your Git repository.

Instead, your application should read the token from the environment:

client.login(process.env.DISCORD_TOKEN);

Then configure:

DISCORD_TOKEN=your-token-here

in the hosting environment.

Also make sure local environment files aren't committed:

.env
.env.local
.env.production

This gives you an important separation:

GitHub stores the application.

The deployment environment stores the secret.

If you're already using a token that was accidentally committed to a public repository, don't just delete the commit and continue using the token.

Rotate it.

Step 3: Connect the GitHub repository

This is where the workflow starts changing.

Rather than SSHing into a server and cloning the repository manually, Deploy Hatch connects to GitHub.

The developer selects the repository they want to deploy.

Conceptually, we're moving from this:

Laptop
  ↓
SSH
  ↓
Server
  ↓
git clone
  ↓
npm install
  ↓
process manager
  ↓
Discord Bot

to this:

GitHub Repository
        ↓
   Deploy Hatch
        ↓
Deployment Worker
        ↓
 Docker Container
        ↓
   Discord Bot

GitHub becomes the source from which the deployment is constructed.

Deploy Hatch can associate deployments with repository information such as the branch and Git revision, making it much easier to understand which version of your bot is actually running.

Step 4: Configure the environment

Before starting the bot, we need to provide the secrets and configuration it expects.

For our example, that means:

DISCORD_TOKEN

A larger bot might also have variables such as:

DATABASE_URL
REDIS_URL
API_KEY
NODE_ENV

Those values belong in the deployment configuration rather than the repository.

The application continues using the normal Node.js environment interface:

const token = process.env.DISCORD_TOKEN;

if (!token) {
  throw new Error("DISCORD_TOKEN is required");
}

client.login(token);

I actually prefer failing explicitly here.

A bot silently attempting to start without required configuration can produce much more confusing deployment failures.

Step 5: Deploy the bot

Now we can create the deployment.

Behind a simple Deploy button, considerably more has to happen.

Deploy Hatch's deployment pipeline is roughly:

Repository selected
        ↓
Deployment created
        ↓
Worker receives deployment
        ↓
Repository prepared
        ↓
Runtime/build configuration
        ↓
Dependencies installed
        ↓
Application prepared
        ↓
Container started
        ↓
Runtime state tracked

For a Node.js Discord bot, the result is a persistent application process running inside an isolated Docker container.

The important distinction is that the browser isn't responsible for keeping your deployment alive.

The deployment becomes work handled by the platform.

You can close the Deploy Hatch dashboard.

You can turn off your computer.

The workload isn't running inside either of them.

Step 6: Check the deployment logs

A green status indicator is useful.

Logs are more useful.

When the bot starts successfully, our earlier example prints:

Logged in as MyBot#1234

That gives us a simple confirmation that the Discord client reached its ready state.

But deployment logs become even more valuable when something goes wrong.

For example:

Error: DISCORD_TOKEN is required

immediately tells us that the environment wasn't configured correctly.

Or maybe dependency installation fails.

Or the application's start command doesn't exist.

Or the process crashes after startup.

The point is that you shouldn't need to SSH into an unknown server and start digging through the filesystem just to discover what happened.

The deployment process should expose enough information to diagnose the workload.

Step 7: Verify the bot from Discord

A deployment isn't successful just because a container exists.

Test the actual application.

Open Discord and confirm the bot appears online.

Then invoke one of its commands.

For example:

/ping

and verify that the expected response appears.

If your bot handles buttons, modals, scheduled jobs, database operations, or other events, test those too.

The full success path isn't:

container started

It's:

repository
   ↓
deployment
   ↓
container
   ↓
Discord connection
   ↓
real bot interaction works

That last step matters.

Step 8: Deploy an update

Now suppose you change your bot.

Maybe /ping originally responds:

Pong!

and you change it to:

Pong! Bot is running.

You commit and push the change to GitHub.

Traditional VPS deployment might send you back into an SSH session to pull the repository and restart the process.

A deployment platform already knows what repository the workload belongs to.

That allows updates to be represented as new deployments of a Git revision rather than manual modifications to a long-lived server.

Deploy Hatch tracks deployment and Git revision information, so the version of the application being deployed isn't just an anonymous copy of whatever happened to exist on a machine.

Deploy the new revision.

Watch the logs.

Verify the bot reconnects.

Test /ping.

Done.

Step 9: Operate the bot without treating the server as the product

Once a workload is running, deployment isn't finished forever.

Applications need operational controls.

Deploy Hatch currently exposes controls for things such as:

Restart

Useful when the workload needs a clean process restart.

Stop

Intentionally stop the running workload.

Redeploy

Build and launch the application again from the desired source revision.

Cancel

Stop deployment work that shouldn't continue.

And because deployment history is retained, the individual deployment becomes something you can inspect rather than treating production as one mysterious server that has slowly accumulated changes over time.

This is one of the reasons I like thinking in deployments instead of servers.

The server becomes infrastructure.

The application becomes the thing the developer operates.

What happens if the deployment worker restarts?

This turned out to be one of the more interesting problems while building Deploy Hatch.

Imagine this:

Deployment Worker
      ↓
Docker
      ↓
Discord Bot

Now restart the worker.

Should the Discord bot die too?

Not necessarily.

The controller and the customer workload have different lifecycles.

A container may still be perfectly healthy even though the worker responsible for managing it restarted.

Destroying every customer workload whenever the deployment service restarts would be a terrible recovery strategy.

So Deploy Hatch workers can discover and adopt existing containers after restart.

Conceptually:

Worker stops
     ↓
Bot container keeps running
     ↓
Worker returns
     ↓
Existing container discovered
     ↓
Runtime state reconciled
     ↓
Worker resumes management

This gets into a broader infrastructure principle:

What should be running and what is actually running aren't always the same thing.

A deployment system needs to compare those states and reconcile differences.

The happy path—clone, install, start—isn't usually the hardest part of building deployment infrastructure.

Recovery is where things get interesting.

Do Discord bots need public HTTPS URLs?

Usually, no.

This is another useful distinction between Discord bots and web applications.

A web application typically needs something like:

Internet
   ↓
HTTPS
   ↓
Reverse Proxy
   ↓
Application Container

Deploy Hatch supports public HTTPS ingress for web workloads.

But a traditional Discord gateway bot generally establishes an outbound connection to Discord.

It doesn't need somebody on the internet to visit a public website hosted by the bot.

That makes Discord bots a particularly good example of a persistent background workload.

They need compute.

They need networking.

They need uptime.

They need logs and lifecycle management.

But they don't necessarily need a public web endpoint.

What about Python Discord bots?

The architecture is fundamentally the same.

Instead of:

package.json
npm install
npm start

you may have Python dependencies and a Python start command.

For example:

import os
import discord

TOKEN = os.environ["DISCORD_TOKEN"]

class Client(discord.Client):
    async def on_ready(self):
        print(f"Logged in as {self.user}")

intents = discord.Intents.default()

client = Client(intents=intents)
client.run(TOKEN)

The infrastructure requirement doesn't change:

the process needs somewhere to continue running after your laptop goes away.

The language changes.

The underlying hosting problem doesn't.

VPS hosting vs a deployment platform

There isn't one correct answer for every project.

A VPS makes sense when you want complete control of the machine.

You may want to configure the operating system yourself, run unusual system-level software, manage your own Docker stack, operate several unrelated services on one box, or simply learn Linux infrastructure.

Those are perfectly legitimate reasons to use one.

A deployment platform makes more sense when your goal is closer to:

Here's my repository. Keep this application running.

You're trading some low-level server control for a higher-level deployment workflow.

For many Discord bot developers, that's a reasonable trade.

Especially when the thing they actually want to spend Saturday building is the bot.

Not its server.

A practical Discord bot deployment checklist

Before considering your bot production-ready, verify:

• Your code is stored in a Git repository.

• The repository has a deterministic start command.

• Dependencies are explicitly declared.

• Your Discord token is not committed to Git.

• Required secrets are configured as environment variables.

• The deployment completes successfully.

• Startup logs show the bot connected to Discord.

• The bot appears online.

• At least one real command or interaction works.

• You know where to inspect logs when something fails.

• You know how to restart or redeploy the workload.

• You can identify which revision of the bot is currently deployed.

That checklist is much more important than whether the underlying machine happens to be called a VPS.

The workflow I'm trying to make boring

Deploy Hatch came from repeatedly running into the gap between:

My application works.

and:

My application is deployed and stays running.

For a Discord bot, I want that gap to look like:

Push code to GitHub
        ↓
Select repository
        ↓
Configure environment
        ↓
Deploy
        ↓
Watch logs
        ↓
Bot stays running

There is still real infrastructure underneath.

Workers still need to schedule workloads.

Containers still need resources.

Deployments still fail.

Processes still crash.

State still needs to be reconciled.

Logs still matter.

The goal isn't to pretend those problems don't exist.

The goal is to stop requiring every bot developer to solve all of them independently.

Try it with your own Discord bot

I'm building Deploy Hatch around this workflow: connect a GitHub repository, configure the application, deploy it into an isolated container, and operate the persistent workload without managing the underlying VPS yourself.

The current beta includes a free project and doesn't require a credit card.

Host a Discord bot with Deploy Hatch → https://deployhatch.com/discord-bot-hosting

I'm documenting the infrastructure behind Deploy Hatch as I build it. If you're interested in Docker, deployment workers, persistent workloads, recovery, GitHub deployments, and the engineering behind developer platforms, I'll be publishing more of the implementation here.

You need somewhere to run it.

You need to get the source code onto that machine, install dependencies, build it, start the right process, keep that process alive, manage environment variables, capture logs, expose ports, route traffic, configure HTTPS, recover from failures, and somehow make all of that repeatable the next time you change the code.

You can absolutely do this yourself.

I've done plenty of it while building Deploy Hatch.

But I wanted the developer-facing workflow to be much simpler:

Connect GitHub → select a repository → deploy → keep it running.

So I built Deploy Hatch around that idea.

From the developer's perspective, a deployment is a few actions in a dashboard.

Underneath, considerably more is happening.

This is a look at that pipeline.

The high-level architecture

At a simplified level, a Deploy Hatch deployment looks like this:

GitHub
   ↓
Deploy Hatch Control Plane
   ↓
Deployment Queue / Data Layer
   ↓
Deployment Worker
   ↓
Build + Runtime Preparation
   ↓
Docker Container
   ↓
Running Workload
   ↓
Public HTTPS Ingress (when applicable)

The control plane and the machines actually running customer workloads are deliberately separate concerns.

The web application handles things such as authentication, GitHub integration, projects, configuration, deployment state, and the developer-facing experience.

Deployment workers handle the infrastructure work required to turn that configuration into a running workload.

That separation has become increasingly important as the platform has grown.

Let's walk through what actually happens.

1. It starts with GitHub

Deploy Hatch integrates with GitHub so a developer can connect repositories without manually copying application source code onto a server.

A project starts with repository selection.

That gives the deployment system important context:

• which repository should be deployed

• which branch or revision is relevant

• the Git commit associated with the deployment

• the configuration needed to build and run the project

Deploy Hatch also keeps Git revision information with deployments.

That matters more than it might initially seem.

"What's running right now?" should have a concrete answer.

When you're debugging a production problem, knowing the exact revision associated with a deployment is much more useful than knowing that somebody deployed "main" at some point.

Deploy Hatch supports branch deployments as well as deployment of specific revisions/commits, with revision verification as part of that workflow.

2. Deploy Hatch figures out how the project should run

Different repositories need different treatment.

A Node.js web application isn't necessarily built the same way as a Discord bot or a background worker.

So part of the deployment process is determining the project's runtime configuration.

Deploy Hatch has detection for:

• runtime

• build command

• start command

The objective isn't to pretend every repository can be understood magically.

It's to eliminate configuration when the correct answer can be determined reliably while still giving the developer control where configuration is necessary.

For a typical project, the platform needs to answer questions such as:

What runtime does this application need?

Does it have a build step?

What command produces the build?

What command starts the application?

Is this a public web application or a persistent background workload?

Those decisions become inputs to the actual deployment worker.

3. Clicking Deploy creates work — it doesn't do the work

One architectural decision I wanted to preserve was not making a browser request responsible for performing an entire deployment.

Building applications can take time.

Containers can fail.

Workers can restart.

Networks can disappear.

A deployment therefore needs to exist as durable work rather than as one long HTTP request hoping nothing goes wrong.

When a deployment starts, Deploy Hatch records that deployment in its data layer and makes it available to the deployment infrastructure.

The worker system can then process it independently of the browser session.

This gives the platform a much better foundation for things like:

• deployment status

• cancellation

• retries and recovery

• deployment history

• worker health

• infrastructure scheduling

• failure diagnostics

The dashboard is showing you what the deployment system is doing.

It isn't the thing doing the build.

4. A deployment worker takes over

Deploy Hatch uses dedicated deployment workers to perform workload operations.

Workers register with the platform and report health/capacity information.

The platform already reasons about concepts including:

• worker health

• available capacity

• reserved resources

• container counts

• regions

• routing information

• ingress capability

This is important because "find a server and run this command" stops being a useful architecture once there is more than one machine.

The control plane needs to understand the infrastructure available to it.

The worker then becomes responsible for turning a deployment request into an actual running workload.

5. The repository becomes a build

Once a worker begins processing a deployment, it prepares the source and executes the project's required build workflow.

For a Node.js application, that may involve installing dependencies and executing a detected or configured build command.

The exact process depends on the project.

What matters to the developer is visibility.

Deploy Hatch streams deployment logs so the build isn't a black box.

Instead of seeing:

Deployment failed

and wondering what happened, the goal is to expose the actual deployment process.

Dependency installation.

Build output.

Runtime startup.

Errors.

The things you'd normally be looking for in a terminal should be visible from the deployment interface.

Improving those diagnostics is an ongoing part of making the deployment experience better, because hiding infrastructure complexity shouldn't mean hiding useful information.

6. The workload runs inside Docker

After preparation and building, Deploy Hatch runs customer workloads using Docker-based isolation.

This gives each deployed workload its own containerized runtime rather than simply launching every customer's process directly on the worker host.

Conceptually:

Worker Host
│
├── Deploy Hatch Worker
│
├── Customer Container A
│   └── Application
│
├── Customer Container B
│   └── Discord Bot
│
└── Customer Container C
    └── API

Containers give the platform a consistent unit for lifecycle and resource management.

Deploy Hatch can reason about a workload as something that can be:

• started

• stopped

• restarted

• inspected

• redeployed

• associated with resource limits

• associated with a specific deployment/revision

The platform also enforces plan/resource constraints server-side rather than relying solely on UI restrictions.

This is one of those areas where building a hosting platform quickly turns into much more than "run Docker."

Starting a container is the easy part.

Operating containers reliably is the interesting part.

7. A successful deployment becomes a managed runtime

Once the container starts, the job isn't over.

Deploy Hatch maintains runtime state and exposes lifecycle controls from the dashboard.

Developers can work with actions such as stopping, restarting, canceling, and redeploying workloads rather than SSHing into the underlying host.

Deployment history and revision metadata provide context around how the running workload got there.

This is particularly important for persistent workloads.

A Discord bot, background worker, or long-running service isn't a request that executes for a few seconds and disappears.

It needs to stay alive.

That requirement was one of the original reasons I started building Deploy Hatch.

I wanted the persistence of a server without making every developer become the administrator of one.

8. Worker restarts created another problem: adoption

Here's where building the platform became more interesting.

What happens if the Deploy Hatch worker restarts but the customer container is still running?

The wrong answer is:

Forget everything and create another container.

A worker process and a customer workload have different lifecycles.

The infrastructure therefore needs to reconcile what the platform believes should exist with what actually exists on the machine.

Deploy Hatch includes worker/container adoption behavior after worker restarts.

Existing containers can be discovered and brought back under management instead of blindly treating every worker restart as a fresh machine.

The platform also has stale-deployment recovery and worker heartbeat functionality to help reconcile infrastructure state.

This is a recurring lesson from building deployment infrastructure:

The happy path is rarely the difficult part.

The difficult part is deciding what the system should do after something dies halfway through the happy path.

9. Public web applications need another layer

A running container doesn't automatically make something a useful web application.

If an application needs to be publicly accessible, traffic still has to reach the correct workload.

Deploy Hatch uses a public deployment namespace:

<deployment-id>.apps.deployhatch.com

Public ingress is handled through Caddy.

At a high level:

Browser
   ↓
HTTPS
   ↓
*.apps.deployhatch.com
   ↓
Caddy / Deploy Hatch Ingress
   ↓
Correct Host + Container Port
   ↓
Running Application

Deploy Hatch maps the public deployment hostname to the appropriate running workload.

TLS is handled at the ingress layer, so a successful public web deployment can receive an HTTPS URL without the developer manually configuring a reverse proxy or certificate.

The dashboard can then expose actions such as:

Open App

and

Copy URL

This sounds like a small UX feature.

Underneath it is DNS, routing, container networking, state reconciliation, and TLS.

That's exactly the kind of infrastructure I want Deploy Hatch to hide until a developer actually needs to care about it.

10. We tested the complete path with a real application

One of the milestones that made the platform feel substantially more real was deploying a Tetris web application through the entire system.

Not a landing-page mockup.

Not a manually deployed application made to look like Deploy Hatch deployed it.

The application actually:

1. went through Deploy Hatch

2. built through the deployment pipeline

3. ran inside a Docker container

4. was routed through Deploy Hatch ingress

5. received an apps.deployhatch.com hostname

6. was served over HTTPS

7. could be opened from the dashboard

We've also run a persistent Discord bot workload through the platform.

Those two tests exercise very different use cases.

One is a public application that needs ingress and HTTPS.

The other is a persistent background workload that needs to remain running without being a traditional website.

Supporting both is important because Deploy Hatch isn't intended to be a static-site host.

The goal is broader:

Give developers a straightforward way to run real workloads without making them operate the underlying servers.

11. Environment variables belong outside the repository

Real applications usually need configuration that shouldn't be committed directly into source control.

API keys.

Database URLs.

Bot tokens.

Application configuration.

Deploy Hatch includes environment-variable management as part of the project/deployment experience.

That allows deployment configuration to remain separate from the Git repository.

This is particularly important for the kinds of persistent workloads Deploy Hatch targets, where a GitHub repository often contains the application while the runtime needs credentials or environment-specific configuration to actually operate.

12. The deployment pipeline is really a reconciliation system

When I started working on deployment infrastructure, it was tempting to think of deployment as a linear script:

clone
install
build
run
done

That model works until reality happens.

A build times out.

A worker restarts.

A container survives when its controller doesn't.

A deployment gets canceled.

A machine becomes unhealthy.

Routing configuration changes.

An existing workload needs to be rediscovered.

The architecture increasingly becomes less about executing a sequence of commands and more about continuously answering:

What should be running?

What is actually running?

Are those two things consistent?

If not, how do we safely reconcile them?

That shift has influenced a lot of Deploy Hatch's infrastructure work.

Worker heartbeats, stale-deployment recovery, container adoption, deployment state, runtime controls, and public URL reconciliation are all pieces of the same larger problem.

What the developer should see

All of that infrastructure exists to make the developer-facing workflow boring.

That's intentional.

The desired experience is still:

Connect GitHub
      ↓
Select Repository
      ↓
Configure
      ↓
Deploy
      ↓
Watch Logs
      ↓
Running Application

For a public web workload:

Running Application
      ↓
HTTPS URL
      ↓
Open App

For a persistent worker or bot:

Running Workload
      ↓
Keep It Running
      ↓
Logs + Runtime Controls

A developer shouldn't need to understand Deploy Hatch's worker recovery logic just to deploy an API.

But the recovery logic still needs to exist.

That's the difference between making infrastructure look simple and actually doing the engineering required to make the experience simple.

What's next

Deploy Hatch is currently in public beta, and I'm working on the developer experience while putting real projects through the platform.

There is still plenty to improve — particularly around deployment UX, detection, diagnostics, logs, onboarding, and documentation.

That's also why I'm writing this series.

Future posts will dig further into individual parts of the system, including:

• building the deployment worker

• container recovery after worker restarts

• automatic HTTPS ingress

• deployment queues

• persistent Discord bot workloads

• runtime and build detection

• resource enforcement

• what happens when deployments fail

I'll share both the parts that work and the engineering problems that show up along the way.

Want to try the pipeline yourself?

Deploy Hatch is currently available in public beta.

Connect a GitHub repository, deploy a project, and see the pipeline from the developer side.

Deploy Hatch: https://deployhatch.com

If you're specifically working with Discord bots:

Discord Bot Hosting: https://deployhatch.com/discord-bot-hosting

For Node.js projects:

Deploy Node.js: https://deployhatch.com/deploy-nodejs

If you hit something confusing or broken, that's useful feedback too.

The goal isn't to pretend deployment infrastructure is simple.

It's to make deploying on it simple.

**Ship the app.

Not the server.**