iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
To run GitLab CI on your own VPS, put a project-root .gitlab-ci.yml in the repository, install GitLab Runner on a supported Linux VPS, create a runner in Settings > CI/CD > Runners, register it with the generated authentication token, and then trigger a pipeline. The runner is the agent that links your VPS to GitLab and executes jobs; the executor you choose determines whether those jobs run directly on the host or inside containers.
What you are building
A self-hosted GitLab CI setup has three parts:
- Pipeline definition: The case-sensitive file
.gitlab-ci.ymlat the repository root defines stages, jobs, scripts, variables, dependencies and conditions. - GitLab Runner: Software installed on your VPS. Registration links that installation to GitLab so it can receive jobs from the project, group or instance.
- Executor: The runtime boundary for each job. A shell executor runs commands directly on the VPS; a Docker executor runs them in containers.
When a commit or manually started pipeline matches the rules in .gitlab-ci.yml, GitLab places an eligible job in the queue. A registered, online runner whose scope and tags match the job requests that work, checks out the code, runs the script, uploads any configured results and reports the status.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsPlan the runner before installing it
Choose the narrowest useful scope
Create a project runner unless several projects genuinely need the same trusted execution environment. A runner can be scoped at three levels:
| Scope | Best fit | Trade-off |
|---|---|---|
| Project | One repository or a small team with a clear trust boundary | Smallest blast radius and simplest ownership; other projects cannot use it. |
| Group | Several related repositories maintained by the same team | Convenient sharing, but every project in the group may be able to schedule work on the runner. |
| Instance | Central administration across a self-managed GitLab instance | Maximum sharing and administrative reach; a mistake or untrusted project can affect many workloads. |
Use a separate runner for production deployment jobs or for projects with a different trust level. GitLab documentation recommends installing production runners on a separate machine for security and performance reasons.
#1 Best Overall
- Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
- With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
- Wide Application:Upgraded attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
- Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
- Warranty & Support: Our Electric air duster comes with 5 years warranty and 24/7 customer service. During this period, if you have any questions,pls kindly feel free to contact us.
Size the VPS from workload, not a universal recipe
There is no single CPU or RAM requirement that fits every GitLab CI workload. Estimate the resources needed by the tools your jobs actually run: compiler and test memory, the number of jobs you want concurrently, container image and dependency downloads, artifact size, cache traffic, disk growth and network throughput. Check that the Linux distribution and CPU architecture are supported by the GitLab Runner version you will install, then choose CPU, memory, disk and network capacity with headroom for peak jobs.
- Small serial scripts may need little compute but still require enough disk for the checkout, dependencies and logs.
- Compilers, browser tests, mobile toolchains and large containers can consume substantially more memory and temporary storage.
- Parallel jobs multiply CPU, memory, disk and network pressure. If the VPS swaps or fills its disk, jobs can fail even when the runner remains online.
Prepare administration and network access
You need administrative access to the VPS, outbound HTTPS connectivity to your GitLab instance, and a firewall policy that permits the runner to reach GitLab and any package, container or dependency registries required by your jobs. A runner normally pulls jobs rather than accepting inbound job connections, so do not expose unnecessary listening services. Keep system updates and time synchronization enabled; a badly skewed clock can make authentication and TLS troubleshooting confusing.
Recommended Free Tools
Create the project pipeline file
Open or create the GitLab project and add a file named exactly .gitlab-ci.yml in the repository root. The leading dot, hyphen, extension and lowercase spelling matter. A minimal sequential pipeline with one build job and one test job looks like this:
stages:
- build
- test
variables:
BUILD_DIR: 'build'
build_app:
stage: build
script:
- mkdir -p "$BUILD_DIR"
- echo 'Build commands go here'
artifacts:
paths:
- build/
test_app:
stage: test
needs:
- build_app
script:
- echo 'Test commands go here'stages establishes the order in which stage groups run. Jobs in the same stage can run in parallel when runners are available. Each job has a name, a stage and a script; the script is the command list executed by the runner. variables supplies reusable values, while needs expresses a dependency that lets a job consume an earlier job’s result without relying only on stage ordering. artifacts tells GitLab which files to retain from the job.
As the pipeline grows, add conditions such as branch or merge-request rules, explicit dependencies, caches and protected deployment jobs deliberately. Keep secrets out of this file. Store them as protected and masked CI/CD variables in the GitLab project or group instead of committing them.
Rank #2
- Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
- Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
- Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
- Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
- Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth
Provision the Linux VPS and install GitLab Runner
- Choose a supported Linux image and architecture. Verify support for the runner release you intend to use and allocate resources for your expected concurrency and toolchain.
- Harden the host. Create an administrative account with the access method you use, apply security updates, restrict inbound firewall rules and avoid installing unrelated services on a runner dedicated to CI.
- Install GitLab Runner from a trusted source. GitLab documents an official Linux package repository as well as package and binary installation methods. Inspect any installation script before running it, confirm that the package source is the one you intend to trust, and install the runner using your distribution’s normal package workflow.
- Confirm the binary is available. Run
gitlab-runner --versionand record the installed version. If the command is not found, check the package installation result and the executable path before attempting registration.
The package normally creates a service account and a system configuration location. On a service installation, the configuration is commonly held at /etc/gitlab-runner/config.toml; verify the actual path shown by your package and service setup. Treat that file as sensitive because it contains runner authentication data and execution settings.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Create the runner in GitLab
- Open the project and go to Settings > CI/CD.
- Expand Runners and choose to create a project runner. Select a group or instance runner instead only when the broader sharing and administration model is intentional.
- Choose whether the runner accepts untagged jobs. Enable this only if jobs without a
tagslist should be allowed to use it. - Assign descriptive tags when the runner provides a specialized capability, such as a Docker environment or a particular toolchain.
- Copy the generated runner authentication token immediately and keep it in a password manager or another protected secret store. Current GitLab workflows use runner creation and authentication tokens; older registration-token workflows are deprecated in current documentation.
Do not put the token in the repository, a ticket, a shell history file that other users can read, or a public command example. If it is exposed, revoke or replace the runner credentials from GitLab and update the VPS configuration.
Register the runner on the VPS
Registration records the GitLab instance URL, authentication token, runner name and executor in the runner configuration. Run the command as the account that owns the service configuration, usually with sudo for a system service.
Interactive registration
The most portable method is:
sudo gitlab-runner registerAnswer the prompts with:
- The URL of your GitLab instance.
- The authentication token copied when you created the runner.
- A name that identifies the VPS and purpose, such as a project-and-environment label.
- The executor:
shellordocker.
For repeatable provisioning, the same values can be supplied as protected environment variables to a non-interactive command:
sudo gitlab-runner register
--url "$GITLAB_URL"
--token "$RUNNER_AUTH_TOKEN"
--name "$RUNNER_NAME"
--executor shellSet those variables only in the protected provisioning session; do not commit them to a script or print the token in logs. Replace shell with docker when you have deliberately prepared Docker on the host.
Rank #3
- 【Large size】：Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
- 【LED backlight mouse pad】：Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
- 【Anti-slip rubber base】：Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
- 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
- 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
Shell executor
With shell, the runner launches job commands directly on the VPS under the runner service account. This is the simplest option when the host already contains the required compiler, language runtime, package manager and test tools. It also has the broadest host access: a job can read or modify anything that the service account can reach, and a poorly controlled script can consume host resources or alter the operating system.
Install every dependency your jobs need on the VPS, pin versions where reproducibility matters, and never expose a shell runner to untrusted code or projects merely because they can reach the same GitLab group.
Docker executor
With docker, each job runs in a container based on the image selected during registration or in the runner configuration. The container boundary keeps most job files and dependencies separate from the host and makes the environment easier to reproduce, but it adds Docker installation, image-pull time, storage management and daemon maintenance.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
During registration, select the Docker executor and provide a default image when prompted. A small image is convenient for a demonstration, but production pipelines should use a deliberately chosen and maintained image, preferably with a pinned version rather than a moving latest tag. Ensure the runner account can communicate with the Docker daemon using a method approved for your security model; membership in a Docker administration group can provide privileges comparable to root, so grant it only on a dedicated, trusted host.
Start the service and prove that jobs run
- Start the installed service with
sudo gitlab-runner start, or use the service manager supplied by your Linux distribution. - Check its state with
sudo gitlab-runner status. If you installed a user-mode process instead of a system service, run it in the appropriate account and keep its process manager configuration consistent. - Run
sudo gitlab-runner verifyto check that registered runners can contact GitLab. In the GitLab Runners page, the runner should appear online. - Commit and push the root-level
.gitlab-ci.yml, or use the project’s pipeline controls to trigger a pipeline for a branch that contains it. - Open the pipeline and job log. A healthy job shows checkout and preparation, the commands from
script, any artifact upload, and a successful completion status.
If the runner is online but the job remains pending, inspect scope, tags, protection settings and the untagged-job choice before changing the VPS.
Rank #4
- 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
- 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
- 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
- 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
- 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
Shell and Docker executors compared
| Consideration | Shell | Docker |
|---|---|---|
| Isolation | Commands run on the host; isolation is limited to the service account and operating-system permissions. | Jobs run in containers, providing a stronger boundary from ordinary host files, though container isolation is not an excuse to run untrusted privileged workloads. |
| Reproducibility | Depends on the packages and versions installed on the VPS. | Image definitions make the userland environment easier to reproduce; image tags and dependencies still need lifecycle management. |
| Startup overhead | Usually minimal because no job container must be created or pulled. | Includes image availability, container creation and cleanup. |
| Host access | Direct access permitted by the runner account, which is powerful and risky. | Normally limited to the container, with access expanded only by explicit mounts or privileged settings. |
| Maintenance | Maintain the OS, language runtimes, compilers and every job dependency on the VPS. | Maintain Docker, image versions, local storage and any host integrations. |
| Good default | Trusted projects needing a simple, host-native environment. | Teams prioritizing repeatable environments and a container boundary. |
Use tags to route jobs correctly
Tags are the routing filter for runners. A job with tags: [docker] can be assigned only to a runner carrying the docker tag. A job with several tags requires a runner that has every listed tag. A job with no tags can use only runners configured to accept untagged jobs.
build_container:
stage: build
tags:
- docker
script:
- echo 'This job requires a runner tagged docker'
host_toolchain_test:
stage: test
tags:
- shell
script:
- echo 'This job requires a runner tagged shell'Use stable capability tags rather than names that become inaccurate when a VPS is replaced. For example, tag by executor and required toolchain, then update the runner’s tags when its capabilities change. If a job is stuck, compare its tags character for character with the tags displayed for online runners.
Secure the runner and its workloads
- Protect authentication data. Restrict permissions on
config.toml, protect backups, and rotate credentials if the token may have been disclosed. - Minimize scope. Prefer project runners for unrelated or differently trusted code. Keep production deployment runners separate from ordinary build runners.
- Protect secrets in GitLab. Use protected and masked CI/CD variables, limit them to protected branches or tags where appropriate, and never echo their values in scripts.
- Do not expose a privileged shell runner. Shell jobs can affect the host and any data reachable by its account. Treat source code from forks and untrusted contributors accordingly.
- Limit Docker privileges. Avoid privileged containers and broad host mounts unless a documented job requirement justifies them. A container executor reduces accidental interference but does not eliminate the consequences of a malicious job.
- Separate production infrastructure. Run deployment-capable runners on dedicated machines, use narrow project or group scope, and require protected branches or tags for deployment jobs.
- Control outbound access where practical. Allow only the registries and services the jobs need, while ensuring GitLab and dependency retrieval remain available.
Maintain the runner after it works
Keep a record of the runner name, scope, tags, executor, VPS owner and installed version. Review the configuration whenever the project changes toolchains or concurrency.
sudo gitlab-runner list
sudo gitlab-runner verify
sudo gitlab-runner status
sudo gitlab-runner restart
sudo gitlab-runner stop
sudo gitlab-runner startUse sudo gitlab-runner run in a controlled foreground session when diagnosing a service problem; return to the managed service for normal operation. The exact service-manager commands and log location depend on the Linux distribution. On systems using systemd, a command such as journalctl -u gitlab-runner can reveal registration, permission, network and executor errors.
Review config.toml after registration and backup it securely without exposing tokens. If you raise the number of concurrent jobs, recheck CPU, memory, disk and network headroom rather than assuming the VPS can absorb the extra load. Remove stale runner registrations from GitLab and the VPS when a machine is decommissioned.
Best Value
- 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
- 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
- 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
- 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
- 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
Troubleshoot common failures
The runner is offline
- Check the VPS is powered on and the runner service is running with
sudo gitlab-runner status. - Inspect service logs for a crash, permission error or invalid
config.toml. - Test outbound HTTPS and DNS resolution to the GitLab instance from the VPS.
- Run
sudo gitlab-runner verify. If verification fails after a token change, update the registration or recreate the runner with a current authentication token. - Confirm the system clock and TLS trust store are current.
The job is stuck or never picked up
- Confirm the runner is online and belongs to the project, group or instance scope that can see the job.
- Compare every job tag with the runner’s tags. A tag mismatch prevents assignment.
- If the job has no tags, confirm the runner accepts untagged jobs.
- Check whether the runner or job is paused, locked to another project, or restricted to protected branches and tags.
- Verify that the job’s rules or conditions actually include the branch, tag or merge request you are testing.
Registration is rejected
Verify that you used the current authentication token generated when creating the runner, not an obsolete registration-token workflow. Check the GitLab URL for spelling and scheme, ensure outbound access is allowed, and confirm that the command is writing to the configuration file used by the service you start. Do not paste the token into a public issue while debugging.
A shell job says a command is missing
The shell executor uses the VPS environment, not the packages on your workstation. Install the required runtime or toolchain on the host, confirm the service account’s PATH, and pin versions when the build depends on a particular release. If different projects need incompatible versions, use separate runners or move the jobs to purpose-built Docker images.
A Docker job cannot start
Check that Docker is installed and its daemon is running, that the runner account has the required access, that the requested image can be pulled, and that the VPS has enough disk space. Review image architecture compatibility and remove stale layers when storage is exhausted. Avoid solving permission errors by enabling unrestricted privileged execution unless the job’s security review explicitly allows it.
The pipeline fails before the script runs
Validate the YAML structure and indentation, confirm the filename is exactly .gitlab-ci.yml at the repository root, and inspect the job log’s preparation section. Missing stages, invalid job keys, unavailable artifacts or unmet needs dependencies can stop a job before its first command.
Quick Recap
Final launch checklist
.gitlab-ci.ymlis at the repository root and defines the intended stages and jobs.- The VPS uses a supported Linux distribution and architecture with resources sized for expected workload and concurrency.
- GitLab Runner was installed from a trusted, documented source and its version is recorded.
- The runner was created at the narrowest appropriate scope with intentional untagged-job and tag settings.
- The authentication token is stored privately and is absent from the repository and logs.
- The selected executor matches the trust boundary and maintenance capability of the team.
- The service is running, verification succeeds, and the runner appears online in GitLab.
- A real pipeline completes successfully, and its job log shows checkout, preparation and script execution.
- Production or deployment workloads use separate, protected runners where their risk warrants it.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
