Deploy on GCP - PipesHub Workplace AI

Overview

This guide will walk you through deploying PipesHub on Google Cloud Platform (GCP) using a Virtual Machine instance. You’ll set up a VM with the required specifications, install Docker, and deploy the PipesHub application.

Database Architecture

PipesHub uses a modern, distributed database architecture:

MongoDB: Primary document store for user data, configurations, and metadata
Neo4j: Graph database for relationships and complex queries
Qdrant: High-performance vector database for semantic search and AI embeddings
Redis: In-memory cache for session management and real-time data, and the default message broker / KV store
Kafka (optional): Used instead of Redis as the message broker, if selected during installation (“full” deployment)

Minimum Requirements

Before you begin, ensure your VM meets these specifications:

CPU: 4 cores (minimum)
RAM: 16 GB (minimum)
Storage: 100 GB SSD or higher (recommended)
- PipesHub uses multiple databases (MongoDB, Neo4j, Qdrant, Redis, and optionally Kafka)
- Storage requirements grow with indexed documents and vector embeddings
OS: Ubuntu 22.04 LTS or 24.04 LTS (recommended)

For production workloads with large document collections, consider 200 GB or more storage to accommodate database growth and vector embeddings.

Recommended GCP VM Instance Types

Choose an instance type based on your workload requirements:

Standard Workloads

n2-standard-4: 4 vCPUs, 16 GB memory
- Balanced performance for most use cases
- Latest generation compute-optimized
n2d-standard-4: 4 vCPUs, 16 GB memory (AMD EPYC)
- Cost-effective alternative with AMD processors

Cost-Optimized

e2-standard-4: 4 vCPUs, 16 GB memory
- Most cost-effective option
- Suitable for steady-state workloads

Deployment Steps

Create a GCP VM Instance

Go to the GCP Console
Navigate to Compute Engine > VM Instances
Click Create Instance
Configure your instance:
- Name: Choose a descriptive name (e.g., pipeshub-prod)
- Region/Zone: Select a region close to your users
- Machine configuration: Select one of the recommended instance types
- Boot disk:
  - Operating system: Ubuntu
  - Version: Ubuntu 22.04 LTS or 24.04 LTS
  - Boot disk type: Balanced persistent disk or SSD persistent disk
  - Size: 100 GB (200 GB recommended for production)
- Firewall:
  - ✅ Allow HTTP traffic
  - ✅ Allow HTTPS traffic
Click Create to launch your instance

Configure Firewall Rules

After creating your VM, configure firewall rules to allow traffic:

Go to VPC Network > Firewall
Click Create Firewall Rule
Configure the rule:
- Name: allow-pipeshub
- Target tags: Add a network tag (e.g., pipeshub-server)
- Source IP ranges: 0.0.0.0/0 (or restrict to your organization’s IP range)
- Protocols and ports:
  - ✅ tcp:80
  - ✅ tcp:443
  - ✅ tcp:3000
Go back to your VM instance and add the network tag under Edit > Network tags

Connect to Your VM

Connect to your VM using SSH:

# Using gcloud CLI
gcloud compute ssh your-instance-name --zone=your-zone

# Or use the SSH button in the GCP Console

Update System Packages

Once connected, update your system:

sudo apt update && sudo apt upgrade -y

Install Docker

Install Docker using the official Docker installation script:

# Add Docker's official GPG key
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

# Install Docker Engine and Docker Compose
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Verify installation
sudo docker --version
sudo docker compose version

For detailed instructions, see the official Docker installation guide.

To run Docker commands without sudo, add your user to the docker group:

sudo usermod -aG docker $USER
newgrp docker

Install Additional Dependencies

Install required network utilities:

sudo apt install -y net-tools nginx git

Install PipesHub

Add your user to the docker group (see the Docker step above) and run newgrp docker (or log out and back in) before this step. curl | bash and later ./install.sh --stop / --uninstall talk to Docker without sudo, so they fail if you skip the group. Commands that start with sudo docker still work without it.The recommended install does not clone the repository. It downloads the installer and writes Compose files into ~/pipeshub:

curl -fsSL https://get.pipeshub.com/install | PIPESHUB_DIR="$HOME/pipeshub" bash
cd ~/pipeshub

When prompted for the Public HTTPS URL, enter your domain (e.g. https://your-domain.com) so OAuth callbacks, webhooks, and browser security checks work correctly.

Never commit the generated .env file to version control. Keep your secrets secure!

For unattended / scripted installs (CI, automation), skip the prompts and pass the public URL directly:

curl -fsSL https://get.pipeshub.com/install \
  | PIPESHUB_DIR="$HOME/pipeshub" PIPESHUB_PUBLIC_URL="https://your-domain.com" bash -s -- --yes
cd ~/pipeshub

The installer will:

Download all required Docker images
Create and start all containers
Wait for PipesHub to pass its health check and print the URL

Later commands in this guide assume you are in ~/pipeshub. The success banner prints that path; --stop, --upgrade, --reconfigure, and --uninstall must run from there.Check the status of your containers:

sudo docker compose -p pipeshub-ai ps

View logs:

sudo docker compose -p pipeshub-ai logs -f

See Advanced Deployment Options for CI environment variables, slim vs. full deployment types, a second instance on the same host, and manual Compose profile usage. To build from source instead, clone the repo and run ./install.sh --build from the repository root.

Stop PipesHub (When Needed)

To stop the services (data preserved):

cd ~/pipeshub
./install.sh --stop

To stop and remove all data (⚠️ use with caution, irreversible):

cd ~/pipeshub
./install.sh --uninstall

Configure HTTPS Access

HTTPS is required for production deployments. PipesHub enforces stricter security checks, and browsers will block certain requests when the application is served over HTTP. If you see a white screen after deployment, this is likely the cause.

You have several options to set up HTTPS:

Option 1: Nginx Reverse Proxy

Configure Nginx as a reverse proxy to terminate HTTPS traffic and forward to the PipesHub frontend:

server {
    listen 80;
    server_name your-domain.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name your-domain.com;

    ssl_certificate /etc/ssl/certs/your-cert.pem;
    ssl_certificate_key /etc/ssl/private/your-key.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Get a free SSL certificate using Let’s Encrypt:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.com

Option 2: Cloudflare Tunnel

Use Cloudflare Tunnel for zero-configuration HTTPS:

# Install cloudflared
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb

# Authenticate
cloudflared tunnel login

# Create and configure tunnel
cloudflared tunnel create pipeshub
cloudflared tunnel route dns pipeshub your-domain.com
cloudflared tunnel run --url http://localhost:3000 pipeshub

Option 3: GCP Load Balancer

Use GCP’s built-in Load Balancer with managed SSL certificates:

Go to Network Services > Load Balancing
Create an HTTPS Load Balancer
Configure backend to point to your VM instance on port 3000
Set up a managed SSL certificate for your domain

For detailed HTTPS setup instructions, refer to the Quickstart Guide.

Access PipesHub

Once deployed, access PipesHub at:

HTTPS (production): https://your-domain.com

The first startup may take a few minutes as Docker pulls images and initializes the databases (MongoDB, the graph DB, Qdrant, Redis, and any optional components you selected).

Post-Deployment Configuration

After accessing PipesHub for the first time:

Complete the onboarding setup
Choose your account type (Individual or Enterprise)
Configure your AI models and connectors
Set up user management and permissions

For detailed onboarding instructions, see the Onboarding Guide.

Troubleshooting

White Screen After Deployment

Cause: You’re accessing PipesHub over HTTP instead of HTTPS. Solution: Set up HTTPS using one of the methods described above.

Cannot Access on Port 3000

Cause: Firewall rules not configured or service not running. Solution:

# Check if containers are running
sudo docker compose -p pipeshub-ai ps

# Verify port is listening
sudo netstat -tulpn | grep 3000

Docker Permission Denied

Cause: User doesn’t have Docker permissions. Solution:

sudo usermod -aG docker $USER
newgrp docker

Out of Memory or CPU Issues

Cause: Instance type doesn’t meet minimum requirements. Solution: Upgrade to a larger instance type with at least 4 cores and 16 GB RAM.

Monitoring and Maintenance

View Logs

pipeshub-ai is a single all-in-one container running the frontend and every backend service, so application logs are all in one place. Database logs are on their own containers.

# All services
sudo docker compose -p pipeshub-ai logs -f

# The application container (frontend + backend services)
sudo docker compose -p pipeshub-ai logs -f pipeshub-ai

# Databases
sudo docker compose -p pipeshub-ai logs -f mongodb
sudo docker compose -p pipeshub-ai logs -f neo4j
sudo docker compose -p pipeshub-ai logs -f qdrant
sudo docker compose -p pipeshub-ai logs -f redis

Check Service Health

# Check running containers
sudo docker compose -p pipeshub-ai ps

# Check resource usage
sudo docker stats

# Check disk usage of volumes
sudo docker system df -v

Update PipesHub

The simplest way to upgrade is to let the installer pull the latest images and recreate containers using your existing .env:

cd ~/pipeshub
./install.sh --upgrade

Prebuilt installs refresh images from Docker Hub; there is no git pull. If you installed from a clone instead, run git pull at the repo root and then ./install.sh --upgrade. To pin a specific version instead of the rolling latest/slim tag, pass --version (or set PIPESHUB_VERSION) before upgrading — see the installer options in the Quickstart Guide.

Backup Data

Never use simple file copy methods (like tar) on live database volumes. This can result in corrupted backups and data loss. Always use native database backup tools or stop the application before backing up.

PipesHub uses multiple databases and storage systems. Choose one of the following backup strategies:

Backup and restore copy-paste blocks cd ~/pipeshub themselves so Compose finds docker-compose.yml and loads COMPOSE_PROFILES from .env. Compose names containers {project}-{service}-1 (default project pipeshub-ai), so use docker compose -p pipeshub-ai exec <service> rather than docker exec mongodb. The kafka-1 service only exists if you selected Kafka as the message broker during installation; if you’re on the default (Redis broker), skip that command.

Option 1: Native Database Tools (Recommended for Production)

Use database-specific backup tools that create consistent snapshots without downtime:

cd ~/pipeshub
set -a
. ./.env
set +a

mkdir -p ~/pipeshub-backups
BACKUP_DATE=$(date +%Y%m%d-%H%M%S)

# Backup MongoDB using mongodump
sudo docker compose -p pipeshub-ai exec -T mongodb mongodump \
  --out=/tmp/mongodb-backup \
  --authenticationDatabase=admin \
  --username="${MONGO_USERNAME}" --password="${MONGO_PASSWORD}"
sudo docker compose -p pipeshub-ai cp mongodb:/tmp/mongodb-backup \
  ~/pipeshub-backups/mongodb-backup-${BACKUP_DATE}
sudo docker compose -p pipeshub-ai exec -T mongodb rm -rf /tmp/mongodb-backup

# Backup Neo4j using neo4j-admin
# `neo4j-admin database dump` requires an OFFLINE database (Community Edition),
# so stop the container and dump directly from its volume via a throwaway container.
# neo4j is profile-gated — COMPOSE_PROFILES must be loaded from ~/pipeshub/.env.
sudo docker compose -p pipeshub-ai stop neo4j
mkdir -p ~/pipeshub-backups/neo4j-backup-${BACKUP_DATE}
sudo docker run --rm \
  -v pipeshub-ai_neo4j_data:/data \
  -v ~/pipeshub-backups/neo4j-backup-${BACKUP_DATE}:/backup \
  neo4j:5.26.0 \
  neo4j-admin database dump neo4j --to-path=/backup
sudo docker compose -p pipeshub-ai start neo4j

# Backup Qdrant using the full-storage snapshot API.
# The qdrant image has no curl, publishes no host port, and requires QDRANT_API_KEY
# (sourced from .env above). Call the API from a curl sidecar on the Compose network
# ({project}_pipeshub → pipeshub-ai_pipeshub). The API only creates the snapshot
# server-side — copy that file out of /qdrant/snapshots.
QDRANT_SNAPSHOT_RESPONSE=$(sudo docker run --rm --network pipeshub-ai_pipeshub curlimages/curl \
  -sS -X POST -H "api-key: ${QDRANT_API_KEY}" 'http://qdrant:6333/snapshots')
QDRANT_SNAPSHOT_NAME=$(echo "$QDRANT_SNAPSHOT_RESPONSE" | grep -oP '"name"\s*:\s*"\K[^"]+')
if [ -z "$QDRANT_SNAPSHOT_NAME" ]; then
  echo "Qdrant snapshot failed: ${QDRANT_SNAPSHOT_RESPONSE}"
else
  sudo docker compose -p pipeshub-ai cp "qdrant:/qdrant/snapshots/${QDRANT_SNAPSHOT_NAME}" \
    ~/pipeshub-backups/qdrant-backup-${BACKUP_DATE}.snapshot
fi

# Backup Redis using BGSAVE (asynchronous — wait until it finishes).
# The installer always writes REDIS_PASSWORD; omit -a only if you cleared it.
REDIS_AUTH=(--no-auth-warning)
[ -n "${REDIS_PASSWORD:-}" ] && REDIS_AUTH+=(-a "${REDIS_PASSWORD}")
REDIS_BGSAVE=$(sudo docker compose -p pipeshub-ai exec -T redis redis-cli "${REDIS_AUTH[@]}" BGSAVE)
echo "${REDIS_BGSAVE}"
if echo "${REDIS_BGSAVE}" | grep -qi 'Background saving started'; then
  while sudo docker compose -p pipeshub-ai exec -T redis redis-cli "${REDIS_AUTH[@]}" INFO persistence \
    | grep -q '^rdb_bgsave_in_progress:1'; do
    sleep 1
  done
  if sudo docker compose -p pipeshub-ai exec -T redis redis-cli "${REDIS_AUTH[@]}" INFO persistence \
    | grep -q '^rdb_last_bgsave_status:ok'; then
    sudo docker compose -p pipeshub-ai cp redis:/data/dump.rdb \
      ~/pipeshub-backups/redis-backup-${BACKUP_DATE}.rdb
  else
    echo "Redis BGSAVE failed — not copying dump.rdb"
  fi
else
  echo "Redis BGSAVE did not start — not copying dump.rdb"
fi

# Backup application data (safe to use tar for non-database files)
sudo docker run --rm \
  -v pipeshub-ai_pipeshub_data:/data \
  -v ~/pipeshub-backups:/backup \
  ubuntu tar czf /backup/pipeshub-data-backup-${BACKUP_DATE}.tar.gz /data

# Backup .env file
cp .env ~/pipeshub-backups/.env.backup-${BACKUP_DATE}

# Create compressed archive of all backups (adjust file list to match your selected components)
tar czf ~/pipeshub-backups/pipeshub-full-backup-${BACKUP_DATE}.tar.gz \
  -C ~/pipeshub-backups \
  mongodb-backup-${BACKUP_DATE} \
  neo4j-backup-${BACKUP_DATE} \
  qdrant-backup-${BACKUP_DATE}.snapshot \
  redis-backup-${BACKUP_DATE}.rdb \
  pipeshub-data-backup-${BACKUP_DATE}.tar.gz \
  .env.backup-${BACKUP_DATE}

echo "Backup completed: pipeshub-full-backup-${BACKUP_DATE}.tar.gz"

Advantages:

Minimal downtime (MongoDB, Qdrant, and Redis are backed up live; only Neo4j is briefly stopped for its offline dump)
Consistent database snapshots
Safe for production environments
Uses native tools designed for each database

Option 2: Stop Application First (Simple and Safe)

If you prefer a simpler approach and can tolerate downtime:

# Create backup directory
mkdir -p ~/pipeshub-backups
BACKUP_DATE=$(date +%Y%m%d-%H%M%S)

# Stop PipesHub (ensures no data is being written)
cd ~/pipeshub && ./install.sh --stop

# Now it's safe to backup volumes using tar
sudo docker run --rm \
  -v pipeshub-ai_mongodb_data:/data/mongodb \
  -v pipeshub-ai_neo4j_data:/data/neo4j \
  -v pipeshub-ai_qdrant_storage:/data/qdrant \
  -v pipeshub-ai_redis_data:/data/redis \
  -v pipeshub-ai_pipeshub_data:/data/pipeshub \
  -v ~/pipeshub-backups:/backup \
  ubuntu tar czf /backup/pipeshub-volumes-backup-${BACKUP_DATE}.tar.gz /data

# Backup .env file
cp .env ~/pipeshub-backups/.env.backup-${BACKUP_DATE}

# Restart PipesHub
cd ~/pipeshub && ./install.sh

echo "Backup completed: pipeshub-volumes-backup-${BACKUP_DATE}.tar.gz"

Advantages:

Simple and straightforward
Single backup file for all data
Guaranteed data consistency
Easy to automate

Automated Backup Script

Create a backup script for regular automated backups:

# Create backup script
cat > ~/backup-pipeshub.sh <<'EOF'
#!/bin/bash
set -e

BACKUP_DIR=~/pipeshub-backups
BACKUP_DATE=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# Stop services
"$HOME/pipeshub/install.sh" --stop

# Backup all volumes
sudo docker run --rm \
  -v pipeshub-ai_mongodb_data:/data/mongodb \
  -v pipeshub-ai_neo4j_data:/data/neo4j \
  -v pipeshub-ai_qdrant_storage:/data/qdrant \
  -v pipeshub-ai_redis_data:/data/redis \
  -v pipeshub-ai_pipeshub_data:/data/pipeshub \
  -v "$BACKUP_DIR":/backup \
  ubuntu tar czf /backup/pipeshub-backup-${BACKUP_DATE}.tar.gz /data

# Restart services
"$HOME/pipeshub/install.sh"

# Delete old backups
find "$BACKUP_DIR" -name "pipeshub-backup-*.tar.gz" -mtime +$RETENTION_DAYS -delete

# Upload to GCS (optional)
# gsutil cp "$BACKUP_DIR/pipeshub-backup-${BACKUP_DATE}.tar.gz" gs://your-bucket/backups/

echo "Backup completed: pipeshub-backup-${BACKUP_DATE}.tar.gz"
EOF

chmod +x ~/backup-pipeshub.sh

# Schedule with cron (daily at 2 AM)
(crontab -l 2>/dev/null; echo "0 2 * * * ~/backup-pipeshub.sh >> ~/pipeshub-backup.log 2>&1") | crontab -

Features:

Automated daily backups at 2 AM
30-day retention policy
Automatic cleanup of old backups
Optional GCS upload for off-site storage
Logging for monitoring

For production environments, upload backups to Google Cloud Storage (GCS) for long-term retention and disaster recovery. Use gsutil to automate uploads.

Restore Data

Always test your backup and restore procedures in a non-production environment before relying on them for disaster recovery.

Choose the restore method that matches your backup strategy:

Restore from Native Backup Tools

Use this method if you created backups using Option 1 (native database tools):

BACKUP_DATE="YYYYMMDD-HHMMSS"  # Replace with your backup date

# Stop PipesHub
cd ~/pipeshub && ./install.sh --stop

# Extract full backup if using compressed archive
cd ~/pipeshub-backups
tar xzf pipeshub-full-backup-${BACKUP_DATE}.tar.gz

# Compose needs the project directory (and .env / COMPOSE_PROFILES) — not the backup folder
cd ~/pipeshub
set -a
. ./.env
set +a

# Start only MongoDB. Neo4j, Qdrant, and Redis restores write into stopped volumes
# (`neo4j-admin database load`, Qdrant `--storage-snapshot`, and Redis AOF vs dump.rdb).
sudo docker compose -p pipeshub-ai up -d mongodb

# Wait for databases to be ready
sleep 10

# Restore MongoDB
sudo docker compose -p pipeshub-ai cp ~/pipeshub-backups/mongodb-backup-${BACKUP_DATE} \
  mongodb:/tmp/mongodb-backup
sudo docker compose -p pipeshub-ai exec -T mongodb mongorestore \
  /tmp/mongodb-backup \
  --drop \
  --authenticationDatabase=admin \
  --username="${MONGO_USERNAME}" --password="${MONGO_PASSWORD}"
sudo docker compose -p pipeshub-ai exec -T mongodb rm -rf /tmp/mongodb-backup

# Restore Neo4j — load directly into its (stopped) volume via a throwaway container
sudo docker run --rm \
  -v pipeshub-ai_neo4j_data:/data \
  -v ~/pipeshub-backups/neo4j-backup-${BACKUP_DATE}:/backup \
  neo4j:5.26.0 \
  neo4j-admin database load neo4j --from-path=/backup --overwrite-destination=true

# Now start Neo4j
sudo docker compose -p pipeshub-ai up -d neo4j

# Restore Qdrant — full-storage snapshots can only be restored via the Qdrant CLI
# at startup (there is no REST API for this), so load it into the volume with a
# throwaway container before bringing the "qdrant" service back up.
sudo docker compose -p pipeshub-ai rm -sf qdrant
sudo docker run -d --name qdrant-restore \
  -v pipeshub-ai_qdrant_storage:/qdrant/storage \
  -v ~/pipeshub-backups:/snapshots \
  qdrant/qdrant:v1.15 \
  ./qdrant --storage-snapshot "/snapshots/qdrant-backup-${BACKUP_DATE}.snapshot"
# Wait for the snapshot to finish loading — check `docker logs qdrant-restore`
# if it needs longer, then remove the throwaway container
sleep 20
sudo docker rm -f qdrant-restore
sudo docker compose -p pipeshub-ai up -d qdrant

# Restore Redis. This stack runs --appendonly yes. If AOF is on at start and
# there is no AOF manifest, Redis creates an empty AOF and ignores dump.rdb.
# Load the RDB with AOF off, then turn AOF on so Redis rewrites AOF from the
# restored dataset before Compose starts it the normal way.
sudo docker compose -p pipeshub-ai stop redis
sudo docker rm -f redis-restore 2>/dev/null || true
sudo docker run --rm \
  -v pipeshub-ai_redis_data:/data \
  -v ~/pipeshub-backups:/backup \
  ubuntu \
  sh -c "rm -rf /data/appendonlydir && cp /backup/redis-backup-${BACKUP_DATE}.rdb /data/dump.rdb"
sudo docker run -d --name redis-restore --network none \
  -v pipeshub-ai_redis_data:/data \
  redis:7.4-bookworm redis-server --appendonly no --dir /data
until sudo docker exec redis-restore redis-cli ping 2>/dev/null | grep -q PONG; do sleep 1; done
sudo docker exec redis-restore redis-cli CONFIG SET appendonly yes
sleep 1
until sudo docker exec redis-restore redis-cli INFO persistence \
  | grep -q '^aof_rewrite_in_progress:0'; do sleep 1; done
sudo docker stop redis-restore && sudo docker rm redis-restore
sudo docker compose -p pipeshub-ai up -d redis

# Restore application data
sudo docker run --rm \
  -v pipeshub-ai_pipeshub_data:/data \
  -v ~/pipeshub-backups:/backup \
  ubuntu tar xzf /backup/pipeshub-data-backup-${BACKUP_DATE}.tar.gz -C /

# Bring the app and remaining profile services back
sudo docker compose -p pipeshub-ai up -d

echo "Restore completed successfully"

Restore from Volume Backup

Use this method if you used Option 2 (stopped application backup):

BACKUP_DATE="YYYYMMDD-HHMMSS"  # Replace with your backup date

# Stop PipesHub
cd ~/pipeshub && ./install.sh --stop

# Remove old volumes
sudo docker volume rm pipeshub-ai_mongodb_data
sudo docker volume rm pipeshub-ai_neo4j_data
sudo docker volume rm pipeshub-ai_qdrant_storage
sudo docker volume rm pipeshub-ai_redis_data
sudo docker volume rm pipeshub-ai_pipeshub_data

# Restore all volumes
sudo docker run --rm \
  -v pipeshub-ai_mongodb_data:/data/mongodb \
  -v pipeshub-ai_neo4j_data:/data/neo4j \
  -v pipeshub-ai_qdrant_storage:/data/qdrant \
  -v pipeshub-ai_redis_data:/data/redis \
  -v pipeshub-ai_pipeshub_data:/data/pipeshub \
  -v ~/pipeshub-backups:/backup \
  ubuntu tar xzf /backup/pipeshub-volumes-backup-${BACKUP_DATE}.tar.gz -C /

# Restore .env file if needed
cp ~/pipeshub-backups/.env.backup-${BACKUP_DATE} .env

# Restart PipesHub
cd ~/pipeshub && ./install.sh

echo "Restore completed successfully"

Restore from Automated Backup Script

If you used the automated backup script:

BACKUP_DATE="YYYYMMDD-HHMMSS"  # Replace with your backup date

# Stop PipesHub
cd ~/pipeshub && ./install.sh --stop

# Remove old volumes
sudo docker volume rm pipeshub-ai_mongodb_data
sudo docker volume rm pipeshub-ai_neo4j_data
sudo docker volume rm pipeshub-ai_qdrant_storage
sudo docker volume rm pipeshub-ai_redis_data
sudo docker volume rm pipeshub-ai_pipeshub_data

# Download from GCS if needed
# gsutil cp gs://your-bucket/backups/pipeshub-backup-${BACKUP_DATE}.tar.gz ~/pipeshub-backups/

# Restore all volumes
sudo docker run --rm \
  -v pipeshub-ai_mongodb_data:/data/mongodb \
  -v pipeshub-ai_neo4j_data:/data/neo4j \
  -v pipeshub-ai_qdrant_storage:/data/qdrant \
  -v pipeshub-ai_redis_data:/data/redis \
  -v pipeshub-ai_pipeshub_data:/data/pipeshub \
  -v ~/pipeshub-backups:/backup \
  ubuntu tar xzf /backup/pipeshub-backup-${BACKUP_DATE}.tar.gz -C /

# Restart PipesHub
cd ~/pipeshub && ./install.sh

echo "Restore completed successfully"

Verify Restore

After restoring, verify that all services are running correctly:

cd ~/pipeshub
set -a
. ./.env
set +a

# Check container status
sudo docker compose -p pipeshub-ai ps

# Check logs for errors
sudo docker compose -p pipeshub-ai logs --tail=50

# Test database connections
sudo docker compose -p pipeshub-ai exec -T mongodb mongosh --eval "db.adminCommand('ping')"
sudo docker compose -p pipeshub-ai exec -T neo4j wget -qO- http://localhost:7474
sudo docker compose -p pipeshub-ai exec -T qdrant bash -c ':> /dev/tcp/127.0.0.1/6333'
if [ -n "${REDIS_PASSWORD:-}" ]; then
  sudo docker compose -p pipeshub-ai exec -T redis redis-cli -a "${REDIS_PASSWORD}" --no-auth-warning ping
else
  sudo docker compose -p pipeshub-ai exec -T redis redis-cli ping
fi

# Access the application
echo "Access PipesHub at https://your-domain.com"

Verification Checklist:

✅ All containers are running
✅ No error messages in logs
✅ All databases respond to health checks
✅ Application UI is accessible
✅ User data is visible
✅ Connectors are functioning

Next Steps

Support

Need help?

📚 Check our FAQ
💬 Join our community discussions
🐛 Report issues on GitHub

​Overview

​Database Architecture

​Minimum Requirements

​Recommended GCP VM Instance Types

​Standard Workloads

​Cost-Optimized

​Deployment Steps

​Configure HTTPS Access

​Option 1: Nginx Reverse Proxy

​Option 2: Cloudflare Tunnel

​Option 3: GCP Load Balancer

​Access PipesHub

​Post-Deployment Configuration

​Troubleshooting

​White Screen After Deployment

​Cannot Access on Port 3000

​Docker Permission Denied

​Out of Memory or CPU Issues

​Monitoring and Maintenance

​View Logs

​Check Service Health

​Update PipesHub

​Backup Data

​Restore Data

​Next Steps

​Support

Overview

Database Architecture

Minimum Requirements

Recommended GCP VM Instance Types

Standard Workloads

Cost-Optimized

Deployment Steps

Configure HTTPS Access

Option 1: Nginx Reverse Proxy

Option 2: Cloudflare Tunnel

Option 3: GCP Load Balancer

Access PipesHub

Post-Deployment Configuration

Troubleshooting

White Screen After Deployment

Cannot Access on Port 3000

Docker Permission Denied

Out of Memory or CPU Issues

Monitoring and Maintenance

View Logs

Check Service Health

Update PipesHub

Backup Data

Restore Data

Next Steps

Support