Migrating a ComfyUI setup from RunPod to TensorDock? This guide explains the hidden complexities and offers three solutions, from a quick manual fix to a robust, automated DevOps workflow for a seamless transition.

Is Switching from RunPod to TensorDock for ComfyUI Worth the Headache? A Senior DevOps Perspective

I remember it like it was yesterday. We had a “simple” request: migrate a critical PostgreSQL database from an old on-prem server, `db-legacy-01`, to a shiny new cloud instance. The plan was solid—dump, transfer, restore. What could go wrong? Three hours into the maintenance window, with production down, we discovered a single, hard-coded IP address buried deep in a legacy application’s config file. A “five-minute” job turned into an all-night firefighting session. This is the exact feeling I get when I see someone asking if it’s “worth it” to move a complex, personalized environment like a ComfyUI setup. It’s never just a copy-paste, and the devil is always in the details.

The Real Problem: Environment Drift and Data Gravity

When you ask about moving from RunPod to TensorDock, you’re not just moving a piece of software. You’re moving an entire ecosystem you’ve built over months. The core issue isn’t about which provider is better; it’s about two critical DevOps concepts:

• Environment Drift: Your RunPod instance isn’t “stock” anymore. You’ve `git clone`’d a dozen custom nodes, `pip install`’d specific Python packages, and maybe even tweaked system libraries. Your new TensorDock instance is a clean slate, and it has no memory of the custom world you built.
• Data Gravity: You likely have tens, if not hundreds, of gigabytes of models, checkpoints, and LoRAs. Moving that much data isn’t trivial. It’s slow, expensive, and error-prone. This “gravity” makes it hard to pull your application away from where the data currently lives.

So, your ComfyUI fails on the new machine not because TensorDock is bad, but because it’s a stranger to your workflow. Let’s fix that. Here are three ways to approach this migration, from the quick and dirty to the professional standard.

---

Solution 1: The “Get It Working NOW” Manual Method

This is the brute-force, get-your-hands-dirty approach. It’s not elegant or repeatable, but sometimes you just need to get back to generating images. You’ll be playing a game of “whack-a-mole” with missing dependencies.

1. SSH into your new TensorDock instance. Get a terminal open and find your ComfyUI directory. It might be in `/workspace`, `/root`, or somewhere else depending on the template you used.
2. Clone your essential custom nodes. You know the ones you can’t live without. Go to the `custom_nodes` directory and clone them one by one.

# Example for installing the ComfyUI Manager
cd /path/to/your/ComfyUI/custom_nodes/
git clone https://github.com/ltdrdata/ComfyUI-Manager.git

3. Download your primary models. Don’t try to move all 150GB at once. Use `wget` to pull down your main SDXL checkpoint and VAE to get things running. You can grab the rest later.

# Navigate to the correct models directory
cd /path/to/your/ComfyUI/models/checkpoints/

# Use wget to download a model (get the direct link)
wget -O juggernautXL_v9.safetensors "https://civitai.com/api/download/models/288922"

Warning: This method is pure technical debt. The next time you switch providers or spin up a new machine, you’ll have to do this all over again. It’s a fix, not a solution.

Solution 2: The “Never Do This Again” DevOps Approach

This is how we do it in the real world. You invest a little time now to build a portable, repeatable environment. The goal is to treat your server (the “instance”) as a disposable cattle, not a precious pet. We’ll use a container and a startup script.

Part A: The Custom Dockerfile

Instead of using a generic template, you define your *exact* environment in a Dockerfile. This file is a recipe that installs ComfyUI, clones all your custom nodes, and sets up the Python environment correctly. Every time you build it, you get a perfect, identical setup.

# Use an official CUDA-enabled base image
FROM pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime

# Set the working directory
WORKDIR /app

# Install git and other dependencies
RUN apt-get update && apt-get install -y git aria2

# Clone the base ComfyUI repository
RUN git clone https://github.com/comfyanonymous/ComfyUI.git

# Clone all your favorite custom nodes
WORKDIR /app/ComfyUI/custom_nodes
RUN git clone https://github.com/ltdrdata/ComfyUI-Manager.git
RUN git clone https://github.com/some-other/awesome-node.git
# ...add all your other nodes here

# Install Python dependencies
WORKDIR /app/ComfyUI
RUN pip install -r requirements.txt

# Set the entrypoint to run ComfyUI
CMD ["python", "main.py", "--listen", "--port", "8188"]

Part B: The Startup Script for Models

You don’t want to bake your huge models into the Docker image. Instead, store them in a cheap object storage bucket (like Wasabi, Backblaze B2, or AWS S3). Then, use the machine’s startup script to sync the models on boot.

#!/bin/bash
# This script runs when the machine starts

# Assuming you've configured your S3 credentials
# Sync checkpoints
aws s3 sync s3://my-comfyui-models/checkpoints /app/ComfyUI/models/checkpoints --no-progress

# Sync LoRAs
aws s3 sync s3://my-comfyui-models/loras /app/ComfyUI/models/loras --no-progress

# Now, launch the application
python /app/ComfyUI/main.py --listen --port 8188

This combination gives you a stateless, portable environment. You can now launch your entire setup on any provider that supports custom containers with a single command.

Solution 3: The “Lift and Shift” with rsync

Okay, sometimes you have a messy, complex setup that you didn’t document, and you just need to move the whole thing, warts and all. This is your “break glass in case of emergency” option. `rsync` is a powerful utility that mirrors directories over a network.

Pro Tip: This can be very slow and may require you to run two instances at once (one on RunPod, one on TensorDock), potentially doubling your costs during the transfer. Use a tool like `screen` or `tmux` so the transfer continues if you get disconnected.

The process is a two-step transfer: RunPod -> Your Local Machine -> TensorDock. Direct server-to-server is possible but can be tricky with firewall and key configurations.

# Step 1: PULL from RunPod to your local computer
# Replace with your actual RunPod SSH details
rsync -avz --progress -e "ssh -p 12345" root@your-runpod-ip.io:/path/to/ComfyUI/ ./ComfyUI_backup/

# Step 2: PUSH from your local computer to TensorDock
# Replace with your actual TensorDock SSH details
rsync -avz --progress -e "ssh" ./ComfyUI_backup/ user@your-tensordock-ip:/path/to/destination/

This literally copies everything. It might work perfectly, or you might have to fix file permissions and paths. It’s a gamble, but it’s a better gamble than manually downloading and uploading 100GB of files.

Which Path Should You Choose?

Here’s a quick breakdown to help you decide.

Method	Speed to First Image	Reproducibility	Long-Term Reliability
1. Manual Fix	Fast (for one model)	None	Very Low
2. DevOps (Docker)	Slow (initial setup)	Excellent	Excellent
3. Rsync Sync	Very Slow (transfer time)	Low	Moderate

My Final Take

Look, I get the appeal of the manual fix. We’ve all done it. But every time you do, you’re just kicking the can down the road. The time you spend fighting with a manual migration is time you could have spent creating a resilient, automated workflow. My strong advice? Take an afternoon to learn the basics of Docker and set up Solution #2. It will transform your workflow from a fragile house of cards into a portable, predictable factory. It’s the difference between constantly fixing things and building things that don’t break.

---

🤖 Frequently Asked Questions