Skip to content
Klutch.sh Docs

Deploying a GitLab App

Introduction

GitLab is a complete DevOps platform delivered as a single application, providing a comprehensive solution for source code management, CI/CD pipelines, issue tracking, and collaboration tools. As an open-source alternative to GitHub, GitLab offers powerful features for software development teams including Git repository hosting, merge requests, code review, wikis, issue boards, and integrated CI/CD capabilities. Self-hosting GitLab on Klutch.sh gives you complete control over your code and development infrastructure.

GitLab stands out for its:

  • All-in-One DevOps Platform: Source control, CI/CD, security scanning, and monitoring in one application
  • Git Repository Management: Full-featured Git hosting with unlimited private repositories
  • Merge Requests & Code Review: Collaborative code review with inline comments and approvals
  • Issue Tracking & Project Management: Agile boards, milestones, labels, and time tracking
  • Built-in CI/CD Pipelines: Automated testing, building, and deployment workflows
  • Container Registry: Integrated Docker container registry for storing images
  • Wiki & Documentation: Built-in wiki system for project documentation
  • Security & Compliance: Vulnerability scanning, dependency checking, and compliance management
  • Self-Hosted Control: Complete data ownership and privacy with on-premises deployment
  • Enterprise Features: LDAP/SAML authentication, advanced permissions, and audit logging

This comprehensive guide walks you through deploying GitLab on Klutch.sh using Docker, including detailed installation steps, PostgreSQL and Redis configuration, persistent storage for repositories and data, and production-ready best practices for running your self-hosted Git platform.

Prerequisites

Before you begin, ensure you have the following:

  • A Klutch.sh account
  • A GitHub account with a repository for your GitLab project
  • Docker installed locally for testing (optional but recommended)
  • Basic understanding of Docker, Git, and database management
  • A PostgreSQL database instance (can be deployed separately on Klutch.sh or use a managed service)
  • A Redis instance for caching and background job processing (can be deployed on Klutch.sh)
  • At least 4GB of RAM allocated for the GitLab container (8GB+ recommended for production)

Understanding GitLab Architecture

GitLab requires several components to function properly:

  • GitLab Rails: The main application server (Ruby on Rails)
  • PostgreSQL: Primary database for storing metadata, users, and configurations
  • Redis: Required for caching, session storage, and background job queuing
  • Gitaly: Git RPC service for handling all Git operations
  • Sidekiq: Background job processor for asynchronous tasks
  • Persistent Storage: For Git repositories, uploads, artifacts, and backups

This guide will help you set up all these components for a production-ready GitLab deployment.

Installation and Setup

Step 1: Create Your Project Directory

First, create a new directory for your GitLab deployment project:

Terminal window
mkdir gitlab-klutch
cd gitlab-klutch
git init

Step 2: Create the Dockerfile

Create a Dockerfile in your project root directory. Klutch.sh will automatically detect and use this Dockerfile for deployment. This configuration uses the official GitLab Community Edition image pinned to a specific version for production stability:

FROM gitlab/gitlab-ce:16.11.1-ce.0


# Set the GitLab external URL (will be overridden by environment variable)
ENV GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.example.com'"


# Expose GitLab HTTP port
EXPOSE 80


# Expose GitLab SSH port
EXPOSE 22


# The GitLab image comes with its own entrypoint
# which handles configuration and startup

Note: Always pin to a specific GitLab version (as shown above) for production deployments. This ensures predictable behavior and allows you to control when updates are applied. Check the GitLab Docker Hub for the latest stable versions.

Step 3: Create GitLab Configuration Script

Create a gitlab.rb.template file to customize GitLab’s configuration. This will be used to generate the GitLab configuration at runtime:

# GitLab URL Configuration
external_url '${GITLAB_EXTERNAL_URL}'


# PostgreSQL Configuration
postgresql['enable'] = false
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'utf8'
gitlab_rails['db_host'] = '${DB_HOST}'
gitlab_rails['db_port'] = '${DB_PORT}'
gitlab_rails['db_database'] = '${DB_NAME}'
gitlab_rails['db_username'] = '${DB_USER}'
gitlab_rails['db_password'] = '${DB_PASSWORD}'


# Redis Configuration
redis['enable'] = false
gitlab_rails['redis_host'] = '${REDIS_HOST}'
gitlab_rails['redis_port'] = '${REDIS_PORT}'
gitlab_rails['redis_password'] = '${REDIS_PASSWORD}'


# Email Configuration (SMTP)
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = '${SMTP_ADDRESS}'
gitlab_rails['smtp_port'] = '${SMTP_PORT}'
gitlab_rails['smtp_user_name'] = '${SMTP_USERNAME}'
gitlab_rails['smtp_password'] = '${SMTP_PASSWORD}'
gitlab_rails['smtp_domain'] = '${SMTP_DOMAIN}'
gitlab_rails['smtp_authentication'] = 'login'
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['gitlab_email_from'] = '${GITLAB_EMAIL_FROM}'
gitlab_rails['gitlab_email_reply_to'] = '${GITLAB_EMAIL_REPLY_TO}'


# GitLab Settings
gitlab_rails['gitlab_default_theme'] = 2
gitlab_rails['time_zone'] = 'UTC'


# Storage paths (these should point to persistent volumes)
git_data_dirs({ "default" => { "path" => "/var/opt/gitlab/git-data" } })


# Disable services we're running externally
postgres_exporter['enable'] = false
redis_exporter['enable'] = false


# Performance tuning (adjust based on available resources)
# For 4GB RAM: 2-3 workers, For 8GB RAM: 4-6 workers
puma['worker_processes'] = 4
sidekiq['concurrency'] = 25


# Security settings
nginx['listen_https'] = false
nginx['listen_port'] = 80

Step 4: Enhanced Dockerfile with Configuration

Update your Dockerfile to include configuration handling:

FROM gitlab/gitlab-ce:16.11.1-ce.0


# Install envsubst for environment variable substitution
RUN apt-get update && apt-get install -y gettext-base && rm -rf /var/lib/apt/lists/*


# Copy GitLab configuration template
COPY gitlab.rb.template /etc/gitlab/gitlab.rb.template


# Create startup script
RUN echo '#!/bin/bash\n\
set -e\n\
\n\
# Substitute environment variables in GitLab config\n\
envsubst < /etc/gitlab/gitlab.rb.template > /etc/gitlab/gitlab.rb\n\
\n\
# Run the original GitLab entrypoint\n\
exec /assets/wrapper "$@"\n\
' > /docker-entrypoint.sh && chmod +x /docker-entrypoint.sh


# Expose ports
EXPOSE 80 22


ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["/bin/sh", "-c", "gitlab-ctl reconfigure && gitlab-ctl tail"]

Step 5: Set Up PostgreSQL Database

GitLab requires PostgreSQL as its primary database. You have two options:

Option A: Deploy PostgreSQL on Klutch.sh

Follow the PostgreSQL deployment guide to set up a PostgreSQL instance on Klutch.sh.

Option B: Use a Managed PostgreSQL Service

Use a managed service like:

Once your database is ready, create a dedicated database for GitLab:

CREATE DATABASE gitlabhq_production;
CREATE USER gitlab WITH PASSWORD 'your_secure_password';
GRANT ALL PRIVILEGES ON DATABASE gitlabhq_production TO gitlab;

Step 6: Set Up Redis

GitLab requires Redis for caching and background job processing.

Option A: Deploy Redis on Klutch.sh

Follow the Redis deployment guide to set up a Redis instance on Klutch.sh.

Option B: Use a Managed Redis Service

Use a managed service like:

Step 7: Configure Environment Variables

In your Klutch.sh app settings, configure the following environment variables:

Database Configuration:

Terminal window
DB_HOST=your-postgres-host.internal
DB_PORT=5432
DB_NAME=gitlabhq_production
DB_USER=gitlab
DB_PASSWORD=your_secure_database_password

Redis Configuration:

Terminal window
REDIS_HOST=your-redis-host.internal
REDIS_PORT=6379
REDIS_PASSWORD=your_redis_password

GitLab Configuration:

Terminal window
GITLAB_EXTERNAL_URL=https://example-app.klutch.sh
GITLAB_ROOT_PASSWORD=initial_root_password_change_me
GITLAB_ROOT_EMAIL=admin@example.com

Email Configuration (SMTP):

Terminal window
SMTP_ADDRESS=smtp.sendgrid.net
SMTP_PORT=587
SMTP_USERNAME=apikey
SMTP_PASSWORD=your_sendgrid_api_key
SMTP_DOMAIN=example.com
GITLAB_EMAIL_FROM=gitlab@example.com
GITLAB_EMAIL_REPLY_TO=noreply@example.com

Optional - For Nixpacks Customization:

If you need to customize the build or start commands, use these environment variables:

Terminal window
NIXPACKS_BUILD_CMD=echo "Custom build step"
NIXPACKS_START_CMD=/docker-entrypoint.sh

Persistent Storage Configuration

GitLab stores critical data that must persist across deployments. You’ll need to attach persistent volumes for the following:

Required Volumes

    1. Git Repositories Volume

      • Mount Path: /var/opt/gitlab/git-data
      • Recommended Size: 50GB minimum (adjust based on expected repository sizes)
      • Purpose: Stores all Git repository data

    2. GitLab Data Volume

      • Mount Path: /var/opt/gitlab
      • Recommended Size: 20GB minimum
      • Purpose: Stores GitLab application data, uploads, and artifacts

    3. Configuration Volume

      • Mount Path: /etc/gitlab
      • Recommended Size: 1GB
      • Purpose: Stores GitLab configuration files

    4. Logs Volume

      • Mount Path: /var/log/gitlab
      • Recommended Size: 10GB
      • Purpose: Stores application logs

Important: In Klutch.sh, when creating volumes, you only specify the mount path and size. The volume names are automatically managed by the platform.

Deploying to Klutch.sh

Follow these steps to deploy GitLab on Klutch.sh:

    1. Push Your Code to GitHub

      Commit your Dockerfile and configuration files:

      Terminal window
      git add Dockerfile gitlab.rb.template
      git commit -m "Add GitLab Docker configuration"
      git push origin main

    2. Create a New App in Klutch.sh

      • Log in to your Klutch.sh dashboard at klutch.sh/app
      • Click “Create New App” or navigate to your project
      • Connect your GitHub repository containing the Dockerfile

    3. Configure Build Settings

      • Klutch.sh will automatically detect the Dockerfile in your repository root
      • No additional build configuration is needed

    4. Set Internal Port

      • In the app settings, set the internal port to 80
      • This is the port inside the container where GitLab listens
      • Klutch.sh will automatically route traffic to this port

    5. Select Traffic Type

      • Select HTTP traffic in the Klutch.sh UI
      • GitLab primarily uses HTTP/HTTPS for web access
      • External access will be available on the standard ports through Klutch.sh’s routing

    6. Add Environment Variables

      • Navigate to the Environment Variables section in your app settings
      • Add all the environment variables listed in Step 7 above
      • Mark sensitive variables (passwords, API keys) as secret

    7. Attach Persistent Volumes

      • Navigate to the Volumes section in your app settings
      • Create and attach volumes for each mount path listed above:
        • /var/opt/gitlab/git-data (50GB+)
        • /var/opt/gitlab (20GB+)
        • /etc/gitlab (1GB)
        • /var/log/gitlab (10GB)
      • Specify the size for each volume based on your expected usage

    8. Configure Instance Resources

      • GitLab requires significant resources:
        • Minimum: 4GB RAM, 2 CPU cores
        • Recommended: 8GB+ RAM, 4+ CPU cores for production
      • Select an appropriate instance size in your app settings

    9. Deploy the Application

      • Click “Deploy” or “Create App”
      • Klutch.sh will build the Docker image from your Dockerfile
      • Monitor the build logs for any errors
      • Initial deployment may take 10-15 minutes as GitLab initializes

    10. Wait for GitLab Initialization

      • After deployment, GitLab needs time to initialize all services
      • This can take 5-10 minutes on the first start
      • Monitor the application logs to track initialization progress
      • You’ll see “gitlab Reconfigured!” when ready

Post-Deployment Configuration

Initial Access

    1. Access GitLab Web Interface

      Open your browser and navigate to your GitLab URL (e.g., https://example-app.klutch.sh)

    2. Initial Root Login

      • Username: root
      • Password: Use the GITLAB_ROOT_PASSWORD you set in environment variables
      • Change the root password immediately after first login

    3. Create Your First Project

      • Click “New Project” in the GitLab dashboard
      • Choose to create a blank project, import, or use a template
      • Set project visibility (Private, Internal, or Public)

    4. Configure Admin Settings

      Navigate to Admin Area → Settings to configure:

      • Sign-up restrictions
      • Account and limit settings
      • User and email restrictions
      • Visibility and access controls

Git Repository Access

GitLab supports two methods for Git operations:

HTTP/HTTPS Access:

Terminal window
git clone https://example-app.klutch.sh/username/project.git

SSH Access (if configured):

For SSH access, you would need to:

  1. Expose port 22 from your container
  2. Configure SSH keys in your GitLab profile
  3. Use TCP traffic type in Klutch.sh (port 8000 for external access)

Note: For most use cases, HTTPS access is recommended and simpler to configure.

Custom Domain Configuration

To use your own domain with GitLab:

    1. Add Custom Domain in Klutch.sh

      • Navigate to your app settings in the Klutch.sh dashboard
      • Go to the Domains section
      • Add your custom domain (e.g., gitlab.yourdomain.com)
      • Follow the DNS configuration instructions provided

    2. Update DNS Records

      Point your domain to Klutch.sh by adding the provided DNS records:

      • Add an A record or CNAME as instructed
      • Wait for DNS propagation (can take up to 48 hours)

    3. Update GitLab Configuration

      • Update the GITLAB_EXTERNAL_URL environment variable to your custom domain:
        Terminal window
        GITLAB_EXTERNAL_URL=https://gitlab.yourdomain.com
      • Redeploy your application for changes to take effect

    4. SSL/TLS Certificate

      Klutch.sh automatically provisions and manages SSL/TLS certificates for your custom domain using Let’s Encrypt.

For more details, see the Custom Domains documentation.

Backup and Restore

Regular backups are critical for GitLab since it contains your source code and project data.

Creating Backups

GitLab includes a built-in backup utility. To create a backup, run this command inside your container:

Terminal window
gitlab-backup create

Backups are stored in /var/opt/gitlab/backups by default (which should be on your persistent volume).

Automated Backup Script

GitLab includes a built-in backup rake task. You can schedule regular backups using GitLab’s cron settings in gitlab.rb:

# Add to gitlab.rb.template
gitlab_rails['backup_keep_time'] = 604800  # Keep backups for 7 days


# Enable backup cron job (runs daily at 2am)
gitlab_rails['backup_cron_enable'] = true
gitlab_rails['backup_cron_minute'] = '0'
gitlab_rails['backup_cron_hour'] = '2'

Alternatively, if you need to create manual backups, you can access the container through Klutch.sh’s console or logs interface and run:

Terminal window
gitlab-backup create BACKUP=daily_$(date +%Y%m%d)

Backing up to external storage:

Configure GitLab to upload backups automatically to object storage:

# Add to gitlab.rb.template for S3-compatible storage
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'aws_access_key_id' => '${AWS_ACCESS_KEY_ID}',
  'aws_secret_access_key' => '${AWS_SECRET_ACCESS_KEY}'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups'
gitlab_rails['backup_multipart_chunk_size'] = 104857600

Restore from Backup

To restore from a backup:

Terminal window
# Stop GitLab services
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq


# Restore from backup file
gitlab-backup restore BACKUP=timestamp_of_backup


# Restart GitLab
gitlab-ctl start

Best Practices:

  • Schedule automated daily backups
  • Store backups in external object storage (AWS S3, Backblaze B2, etc.)
  • Test restore procedures regularly
  • Keep at least 7 days of backups
  • Back up configuration files separately (/etc/gitlab directory)

Security Best Practices

Authentication & Authorization

    1. Change Default Passwords

      • Immediately change the root password after first login
      • Enforce strong password policies in Admin settings

    2. Enable Two-Factor Authentication (2FA)

      • Enable 2FA for your root account
      • Consider requiring 2FA for all users

    3. Configure Sign-up Restrictions

      • Disable public sign-ups if not needed
      • Use email domain restrictions for internal deployments
      • Enable account approval workflows

    4. Set Up User Permissions

      • Use Groups and Projects for organizing users
      • Assign appropriate permission levels (Guest, Reporter, Developer, Maintainer, Owner)
      • Regularly audit user access

Network Security

    1. Use HTTPS Only

      • Ensure GITLAB_EXTERNAL_URL uses https://
      • Klutch.sh provides automatic SSL/TLS

    2. IP Allowlisting

      • Consider restricting admin access by IP if possible
      • Use VPN for sensitive operations

    3. Rate Limiting

      • Enable rate limiting in GitLab settings
      • Configure login attempt limits

Data Security

    1. Encrypt Sensitive Data

      • Use encrypted volumes for persistent storage
      • Ensure database connections use SSL

    2. Secure Environment Variables

      • Mark all sensitive environment variables as secrets in Klutch.sh
      • Never commit secrets to your repository

    3. Regular Updates

      • Keep GitLab updated to the latest stable version
      • Subscribe to GitLab security announcements
      • Update your Dockerfile with new version tags

Monitoring and Maintenance

Health Checks

GitLab provides several endpoints for monitoring:

  • Health Check: https://example-app.klutch.sh/-/health
  • Readiness Check: https://example-app.klutch.sh/-/readiness
  • Liveness Check: https://example-app.klutch.sh/-/liveness

Monitor these endpoints to ensure GitLab is running properly.

Performance Monitoring

    1. Monitor Resource Usage

      • Track CPU, memory, and disk usage in Klutch.sh dashboard
      • GitLab recommends at least 4GB RAM for small teams
      • Scale up resources as your team and repository size grows

    2. Database Performance

      • Monitor PostgreSQL query performance
      • Regularly run VACUUM and ANALYZE on the database
      • Consider connection pooling for high-load scenarios

    3. Background Jobs

      • Monitor Sidekiq queue sizes
      • Increase Sidekiq workers if queues grow large
      • Check for failed jobs in Admin → Monitoring → Background Jobs

Log Management

View GitLab logs for troubleshooting:

Terminal window
# View all logs
gitlab-ctl tail


# View specific service logs
gitlab-ctl tail nginx
gitlab-ctl tail postgresql
gitlab-ctl tail redis

Logs are stored in /var/log/gitlab (ensure this is on a persistent volume).

Troubleshooting

Common Issues and Solutions

Issue: GitLab is not starting or shows 502 errors

  • Solution: Check if GitLab services are fully initialized
    Terminal window
    gitlab-ctl status
  • Wait 5-10 minutes after deployment for all services to start
  • Check logs with gitlab-ctl tail for specific errors
  • Ensure you have allocated enough memory (minimum 4GB)

Issue: Cannot connect to PostgreSQL database

  • Solution:
    • Verify database environment variables are correct
    • Ensure database is running and accessible
    • Check network connectivity between GitLab and database
    • Verify database user has proper permissions

Issue: Redis connection errors

  • Solution:
    • Verify Redis host and port in environment variables
    • Ensure Redis instance is running
    • Check Redis password if authentication is enabled
    • Verify network access to Redis

Issue: High memory usage

  • Solution:
    • GitLab is memory-intensive by design
    • Reduce Unicorn worker processes in gitlab.rb
    • Reduce Sidekiq concurrency
    • Consider upgrading to a larger instance size

Issue: Slow performance

  • Solution:
    • Increase allocated CPU and RAM
    • Optimize PostgreSQL configuration
    • Enable Redis caching
    • Consider using external object storage for artifacts and LFS

Issue: Backup failures

  • Solution:
    • Ensure adequate disk space in /var/opt/gitlab/backups
    • Check backup directory permissions
    • Verify external storage configuration if using remote backups
    • Review GitLab backup logs for specific errors

Issue: Email notifications not working

  • Solution:
    • Verify SMTP environment variables
    • Test SMTP connection from container
    • Check email logs in /var/log/gitlab/gitlab-rails/production.log
    • Ensure SMTP provider allows connections from your server

Issue: Git operations timing out

  • Solution:
    • Increase GitLab timeout settings
    • Check network latency
    • For large repositories, consider increasing HTTP timeout
    • Enable Git LFS for large binary files

Scaling GitLab

As your team grows, you may need to scale GitLab:

Vertical Scaling

  • Increase CPU and RAM allocation in Klutch.sh
  • Recommended: 2GB RAM per 100 users
  • Monitor resource usage and scale proactively

Horizontal Scaling Considerations

GitLab Community Edition has limitations on horizontal scaling, but you can:

  • Use external PostgreSQL with replication
  • Implement Redis Sentinel for high availability
  • Use object storage (S3) for artifacts and LFS
  • Consider GitLab Premium for advanced scaling features

Performance Optimization

    1. Database Optimization

      • Use PostgreSQL connection pooling (PgBouncer)
      • Regular database maintenance (VACUUM, REINDEX)
      • Monitor and optimize slow queries

    2. Object Storage

      • Move artifacts to S3-compatible storage
      • Use object storage for LFS objects
      • Store uploads in external storage

    3. Caching

      • Ensure Redis is properly configured
      • Enable HTTP caching for static assets
      • Use CDN for serving static content

Advanced Configuration

LDAP/Active Directory Integration

For enterprise deployments, integrate with LDAP:

# Add to gitlab.rb.template
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = {
  'main' => {
    'label' => 'LDAP',
    'host' =>  'ldap.example.com',
    'port' => 389,
    'uid' => 'sAMAccountName',
    'bind_dn' => 'CN=query,DC=example,DC=com',
    'password' => 'password',
    'encryption' => 'plain',
    'base' => 'DC=example,DC=com'
  }
}

Container Registry

Enable GitLab’s built-in Docker registry:

# Add to gitlab.rb.template
registry_external_url 'https://registry.example.com'
gitlab_rails['registry_enabled'] = true

GitLab Runner Integration

To enable CI/CD pipelines, deploy GitLab Runner:

    1. Deploy a separate GitLab Runner instance on Klutch.sh
    2. Register the runner with your GitLab instance
    3. Configure runner to execute CI/CD jobs
    4. Use Docker-in-Docker or shell executors

For detailed runner setup, see the GitLab Runner documentation.

Migration from Other Git Platforms

Migrating from GitHub

GitLab provides built-in importers:

    1. In GitLab, go to “New Project”
    2. Select “Import Project” → “GitHub”
    3. Authenticate with GitHub
    4. Select repositories to import
    5. GitLab will import code, issues, and pull requests

Migrating from Bitbucket

Similar process:

    1. Go to “New Project” → “Import Project”
    2. Select “Bitbucket Cloud” or “Bitbucket Server”
    3. Authenticate and select repositories
    4. Import will preserve code and metadata

Manual Migration

For custom migrations:

Terminal window
# Clone existing repository
git clone --mirror https://github.com/user/repo.git
cd repo.git


# Push to GitLab
git push --mirror https://example-app.klutch.sh/user/repo.git

Example: Complete Setup Script

Here’s a complete example to set up your GitLab project locally:

setup-gitlab.sh
#!/bin/bash
# Create project directory
mkdir gitlab-klutch && cd gitlab-klutch


# Initialize git repository
git init


# Create Dockerfile
cat > Dockerfile << 'EOF'
FROM gitlab/gitlab-ce:16.11.1-ce.0


RUN apt-get update && apt-get install -y gettext-base && rm -rf /var/lib/apt/lists/*


COPY gitlab.rb.template /etc/gitlab/gitlab.rb.template


RUN echo '#!/bin/bash\n\
set -e\n\
envsubst < /etc/gitlab/gitlab.rb.template > /etc/gitlab/gitlab.rb\n\
exec /assets/wrapper "$@"\n\
' > /docker-entrypoint.sh && chmod +x /docker-entrypoint.sh


EXPOSE 80 22


ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["/bin/sh", "-c", "gitlab-ctl reconfigure && gitlab-ctl tail"]
EOF


# Create GitLab configuration template
cat > gitlab.rb.template << 'EOF'
external_url '${GITLAB_EXTERNAL_URL}'
postgresql['enable'] = false
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_host'] = '${DB_HOST}'
gitlab_rails['db_port'] = '${DB_PORT}'
gitlab_rails['db_database'] = '${DB_NAME}'
gitlab_rails['db_username'] = '${DB_USER}'
gitlab_rails['db_password'] = '${DB_PASSWORD}'
redis['enable'] = false
gitlab_rails['redis_host'] = '${REDIS_HOST}'
gitlab_rails['redis_port'] = '${REDIS_PORT}'
nginx['listen_port'] = 80
EOF


# Create README
cat > README.md << 'EOF'
# GitLab on Klutch.sh


This repository contains the Docker configuration for deploying GitLab on Klutch.sh.


## Prerequisites
- PostgreSQL database
- Redis instance
- Persistent volumes configured


## Deployment
Push this repository to GitHub and deploy via Klutch.sh dashboard.
EOF


# Commit files
git add .
git commit -m "Initial GitLab configuration"


echo "GitLab project setup complete!"
echo ""
echo "Next steps:"
echo "1. Create a new GitHub repository at https://github.com/new"
echo "2. Add the remote: git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPO.git"
echo "3. Push your code: git push -u origin main"
echo "4. Deploy via Klutch.sh dashboard at https://klutch.sh/app"

Run this script to quickly set up your project structure.

Resources