MARKETPLACE / Development

GitLab on FibaCloudBring code, reviews and delivery into one workflow.

Give your team a shared place to develop and review code. A GitLab deployment brings together repositories and collaboration, while pipeline runners, persistent data and access controls need their own capacity and operating decisions.

Configure a cloud instance Browse the catalogue

GitLabFIBACLOUD

Separate collaboration from job execution

Application context Deployment decisions Maintenance planning

01 / GitLab

Plan for the development lifecycle, not only Git storage.

GitLab connects source control with issues, merge requests and delivery workflows. A self-hosted deployment can give a team control over its application environment and access policies. The chosen edition, license and configuration determine which features are available; a Marketplace listing should not be treated as a promise of every GitLab capability.

Repository size is only one part of the workload. Build jobs, artifacts, package data, logs and container images can grow independently. Decide where runners execute, how untrusted jobs are isolated and which data must be recovered together. Keep deployment credentials out of repositories and define who can change protected branches and release settings.

Product engineering teams

Connect code review, issue tracking and release preparation in one application. Model project permissions around actual responsibilities, with a clear route for reviewing and approving changes before they reach production.

CI and delivery workflows

Use runners to execute the jobs your projects define. Size and isolate runner capacity for the build workload rather than assuming the GitLab application server should also perform every build.

Private project collaboration

Organise repositories for internal teams or selected external collaborators. Review account onboarding, access expiry and project visibility so collaboration does not gradually expand permissions beyond the intended audience.

02 / DEPLOYMENT DECISIONS

Choose the scope before the instance.

Confirm the current image, operating system, software versions and license requirements in the cloud configuration.

GitLab deployment decisions
Decision	What to review	Why it matters
Edition and entitlement	Confirm the image edition, available GitLab features and any subscription requirement.	Installing a package does not establish entitlement to all licensed capabilities.
Runner isolation	Choose where jobs execute and how they access source, secrets and deployment targets.	Build code can perform actions with the runner’s permissions.
Persistent data	Estimate repositories, artifacts, registry content and logs as distinct growth areas.	Storage retention policies influence capacity and restore time.
Recovery compatibility	Document the installed version, configuration, secrets and GitLab backup procedure.	Restoring application data requires compatible software and the supporting configuration.

THE OPERATING VIEW

Separate collaboration from job execution

An example delivery path. Runner placement, credentials and access to release targets should be designed separately from repository hosting.

01Developer & review
02GitLab projects
03Isolated runners
04Release targets

An example delivery path. Runner placement, credentials and access to release targets should be designed separately from repository hosting.

FROM PLAN TO OPERATION

Build a process you can repeat.

Validate the application and prepare its operating process before depending on it for daily work.

01
Review the deployment image
Confirm edition, operating system, supported installation path and resource requirements before configuring the cloud instance.
02
Establish identity and access
Set the public hostname and HTTPS, configure authentication and review default account, group and project permissions.
03
Introduce runners deliberately
Register runners for the required jobs, restrict privileged execution and validate how variables and deployment credentials are exposed.
04
Test the operating process
Exercise a representative pipeline, review logs and capacity, and rehearse the documented backup and restore procedure before expanding use.

PRACTICAL QUESTIONS

Before you move forward.

Clarify the application and operating requirements before choosing the deployment.

Discuss your requirements

Are pipeline runners included with the application server?

Review the available image and deployment configuration. Runners execute CI jobs and require explicit registration, permissions and capacity planning even when they run near the GitLab application.

Does the listing include every GitLab feature?

Feature availability depends on the installed edition and any applicable subscription. Review the image details and GitLab licensing before designing a workflow around a particular capability.

What should a GitLab recovery plan include?

Follow GitLab’s procedure for application data and separately retain required configuration and secrets. Include external artifact or registry storage where used, and test recovery with a compatible application version.

Can development and production use the same runner?

Decide this from the trust boundary and job permissions. Separating runners for untrusted changes and production delivery can reduce the chance that a development job reaches sensitive deployment credentials.

OFFICIAL DOCUMENTATION

Go deeper with the application’s own guidance.

Use the documentation for the product and version selected at deployment.

FIBACLOUD / GitLab

Turn the plan into your next deployment.

Review the available configuration and choose the resources for your project.

Configure a cloud instance Discuss your requirements

Compute

Storage

Networking & security

GitLab on FibaCloudBring code, reviews and delivery into one workflow.