SecureAnyCloud
Deployment guide

GitLab

Overview

GitLab is a complete DevOps platform. In a single application it provides Git repository management, CI/CD pipelines, issue tracking, code review and more.

This SecureAnyCloud AMI delivers GitLab Community Edition on Linux through the AWS Marketplace, with an integrated PostgreSQL database and ready-made scripts that set the GitLab URL for you.

What you get:

  • GitLab Community Edition with the web interface on port 80
  • An integrated PostgreSQL database at /var/opt/gitlab/postgresql
  • Preconfigured URL setup scripts for a private IP, a public IP or a DNS hostname
  • Automatic startup on boot through the GitLab services
  • An OS package update script that keeps the system current
  • AWS CLI v2 for AWS service integration
  • Systems Manager Agent (SSM) for remote management
  • CloudWatch Agent for monitoring
  • Latest security patches applied at build time
  • 24/7 SecureAnyCloud support with a 24-hour response SLA

Prerequisites

Before you launch the AMI, make sure you have:

  • An active AWS account
  • An active subscription to the GitLab listing on AWS Marketplace
  • An EC2 key pair for SSH access
  • Familiarity with EC2 instance management and SSH

Recommended instance type: t3.large (2 vCPU, 8 GB RAM) or larger. The minimum requirements are 2 vCPU, 4 GB RAM and 20 GB of disk space. GitLab is resource-intensive and performs best with ample memory.

1

Launch the AMI

  • Open the AWS Marketplace and search for "GitLab SecureAnyCloud".
  • Click Continue to Subscribe, accept the terms, then click Continue to Configuration.
  • Select your Region and Software Version.
  • Click Continue to Launch.
  • Choose Launch through EC2 for full control over instance configuration.
  • Select your instance type (t3.large is recommended).
  • Configure storage: 20 GB gp3 is the minimum. Use 50 GB or more for active repositories.
  • Configure your Security Group with the inbound rules below.
  • Select your EC2 key pair and launch the instance.

Inbound rules for the Security Group:

  • Port 22 (TCP) from your IP: SSH access
  • Port 80 (TCP) from your IP: GitLab web interface
  • Port 5432 (TCP) from your IP: PostgreSQL database (restrict to your VPC)

Important: Allow port 5432 (PostgreSQL) only from within your VPC or from specific trusted IPs. Do not expose the database to the public internet.

2

Connect over SSH

When your instance is running and has passed both status checks (2/2), connect over SSH:

ssh -i your-key.pem ec2-user@<public-ip-address>

Replace your-key.pem with the path to your EC2 key pair and <public-ip-address> with your instance's public IP.

Important: Wait until the instance reaches 2/2 successful status checks before you connect. If you connect too early, you may see an error such as:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

This is expected during the initial boot. Wait for both status checks to pass, then try again.

To switch to the root user, run:

sudo su -
3

Configure the GitLab URL

Three URL configuration scripts are provided under /stage/scripts/. Run the one that matches your use case. Each script updates the external_url setting in /etc/gitlab/gitlab.rb and runs gitlab-ctl reconfigure.

Note: The reconfigure takes about 3 minutes and 20 seconds on average, measured on t3.medium, t3.large and t3.xlarge instance types.

Option A: Use the private IP address

Choose this if you access GitLab from within the same VPC:

/stage/scripts/gitlab-ce-set-private-url.sh

GitLab is then available at http://PRIVATE_IP_OF_YOUR_EC2_INSTANCE

Option B: Use the public IP address

Choose this if you access GitLab from the internet:

/stage/scripts/gitlab-ce-set-public-url.sh

GitLab is then available at http://PUBLIC_IP_OF_YOUR_EC2_INSTANCE

Option C: Use a DNS hostname

Choose this if you have a custom domain that points to your instance:

/stage/scripts/gitlab-ce-set-dns-hostname-url-http.sh

GitLab is then available at http://DNS_HOSTNAME_OF_YOUR_CHOOSING

Expected output when any script completes successfully:

Notes: Default admin account has been configured with following details: Username: root Password: You didn't opt-in to print initial root password to STDOUT. Password stored to /etc/gitlab/initial_root_password. This file will be cleaned up in first reconfigure run after 24 hours. NOTE: Because these credentials might be present in your log files in plain text, it is highly recommended to reset the password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password. gitlab Reconfigured!
4

Log in to GitLab

Open a web browser and go to the URL you configured in Step 3. The GitLab login page appears. Sign in with:

  • Username: root
  • Password: the password in the file generated on the instance. Read it with the command below.
cat /etc/gitlab/initial_root_password

Important: GitLab deletes this password file automatically after 24 hours. Save the password, or change it promptly using the steps below.

5

Change the root password

Change the default root password immediately after your first login. You can do it from the web interface or the command line.

Method 1: From the GitLab web interface

  • Log in as root.
  • Open your user profile settings.
  • Change your password in the Password section.

Method 2: From the command line

As the root OS user, run:

gitlab-rake "gitlab:password:reset[root]"

The prompt takes about 30 seconds to return. Then enter your new password:

[root@ip-172-31-87-42 scripts]# gitlab-rake "gitlab:password:reset[root]" Enter password: Confirm password: Password successfully updated for user with username root. [root@ip-172-31-87-42 scripts]#

You can now log in with the username root and your new password. GitLab is ready to use.

Server components

Install locations:

  • GitLab Community Edition: /etc/gitlab/gitlab.rb
  • PostgreSQL database: /var/opt/gitlab/postgresql

Note: The automatic OS package update script can update component versions on first boot.

Filesystem layout

Mount points:

  • / (38 GB): root filesystem
  • /boot (2 GB): operating system kernel files
  • /var/opt/gitlab (9.8 GB): GitLab data directory (repositories, uploads, packages)

Key GitLab directories:

  • /etc/gitlab: GitLab configuration files
  • /etc/gitlab/gitlab.rb: main configuration file
  • /var/opt/gitlab: application data (repos, database, uploads)
  • /var/opt/gitlab/postgresql: PostgreSQL database files
  • /var/opt/gitlab/git-data: Git repository storage
  • /var/log/gitlab: GitLab service logs

Manage GitLab services

GitLab manages its own services through gitlab-ctl.

Check service status:

gitlab-ctl status

Stop all GitLab services:

gitlab-ctl stop

Start all GitLab services:

gitlab-ctl start

Restart all GitLab services:

gitlab-ctl restart

Reconfigure GitLab (required after you change /etc/gitlab/gitlab.rb):

gitlab-ctl reconfigure

View GitLab logs:

gitlab-ctl tail

Scripts and log files

All of these live in /stage/scripts:

  • initial_boot_update.sh: updates the OS with the latest packages on first boot
  • initial_boot_update.log: output log for the boot update script
  • gitlab-ce-set-private-url.sh: sets the GitLab URL to the instance private IP
  • gitlab-ce-set-public-url.sh: sets the GitLab URL to the instance public IP
  • gitlab-ce-set-dns-hostname-url-http.sh: sets the GitLab URL to a DNS hostname

On startup

An OS package update script runs on first boot so that the image is fully up to date. To disable it, remove the script and its crontab entry:

rm -f /stage/scripts/initial_boot_update.sh crontab -e
# Delete the following line, save and exit: @reboot /stage/scripts/initial_boot_update.sh

Troubleshooting

Cannot reach the GitLab web interface on port 80

  • Verify that the GitLab services are running: gitlab-ctl status
  • Check that your security group allows inbound traffic on port 80 from your IP.
  • Make sure you ran one of the URL configuration scripts from Step 3.
  • Check the GitLab logs for errors: gitlab-ctl tail

GitLab is slow or uses too much memory

  • GitLab requires at least 4 GB of RAM. On a smaller instance, upgrade to t3.large or larger.
  • Monitor memory usage: free -m
  • Consider increasing swap space if memory is constrained.
  • Reduce the number of Sidekiq workers in /etc/gitlab/gitlab.rb.

GitLab reconfigure fails

  • Check for syntax errors in /etc/gitlab/gitlab.rb.
  • Review the reconfigure log: gitlab-ctl tail reconfigure
  • Make sure the disk has enough free space: df -h

Cannot log in with the root password

  • After the 24-hour window, GitLab deletes the /etc/gitlab/initial_root_password file.
  • Reset the password from the command line: gitlab-rake "gitlab:password:reset[root]"

502 error when you open GitLab

  • GitLab may still be starting. Wait 2 to 3 minutes and refresh.
  • Check that all services are running: gitlab-ctl status
  • Restart GitLab: gitlab-ctl restart

Security notes

  • Change the default root password immediately after your first login.
  • Restrict port access. Allow port 80 only from trusted IPs. Never expose port 5432 publicly.
  • Enable HTTPS. Configure SSL in /etc/gitlab/gitlab.rb using Let's Encrypt or your own certificate.
  • Disable public registration. Go to Admin Area > Settings > General > Sign up restrictions and clear "Sign up enabled".
  • Enable two-factor authentication. Encourage or enforce 2FA for all users.
  • Configure backup schedules. Set up automated backups with gitlab-backup create.
  • Keep GitLab updated. Update the GitLab packages regularly with yum update gitlab-ce.
  • Monitor logs. Review /var/log/gitlab/ for suspicious activity.

Support

If you run into any issue with this product, contact SecureAnyCloud support:

  • Email: sales@secureanycloud.com
  • Website: secureanycloud.com
  • Support hours: 24/7, with a 24-hour response SLA

Deploy on AWS

Launch GitLab with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com