TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

GitLab Serverless

2 posts · Jan 2018 – May 2026

What this trail covers

GitLab is decomposing its monolithic PostgreSQL database into independent databases, starting with the separation of CI-related data. This involved extensive planning, proof-of-concept work, and the development of tools and documentation to manage cross-database dependencies, such as cross-join detection, cross-database transaction detection, and loose foreign keys. The project leveraged Rails' multi-database support and addressed challenges like mirroring data. This post details a major version of this decomposition, specifically the general availability of Gitaly on Kubernetes, allowing for a fully Kubernetes-native GitLab deployment and consolidation of infrastructure by moving Gitaly into the cluster. This eliminates the need to maintain and monitor a separate VM fleet alongside Kubernetes nodes.

All GitLab trails
  1. Consolidate your GitLab stack with Gitaly on KubernetesThis post announces the general availability of Gitaly on Kubernetes, a significant step in consolidating GitLab's infrastructure. It details the technical challenges of running Gitaly in Kubernetes, such as memory-intensive Git operations, OOM event mitigation using cgroups, and the complexities of Pod restarts. The solution involved mounting `/sys/fs/cgroup` via an init container and making client retries configurable to avoid downtime during upgrades. Benchmarks are provided to demonstrate near-identical success rates for Git operations between Gitaly on VMs and Gitaly on Kubernetes. The post also highlights the benefits for users running GitLab in hybrid mode or adopting GitLab for the first time on Kubernetes.
  2. Enable secure sudo access for GitLab Remote Development workspacesThis post introduces the capability to enable secure sudo access for GitLab Remote Development workspaces. It details the challenge of needing elevated privileges within workspaces for tasks like package installation and debugging, and how this is prevented by default due to security measures. The post then explains three methods to enable this secure sudo access: Sysbox, Kata Containers, and user namespaces, providing Kubernetes and GitLab agent configuration details for each. It concludes with a demonstration of creating a workspace with these configurations and successfully installing and using `jq` for log analysis.
  3. How to deploy AWS Lambda applications with easeThis post details a webcast demonstrating how to use GitLab CI/CD with AWS Serverless Application Model (SAM) to build, test, and deploy AWS Lambda applications. It explains what AWS SAM is, its benefits for enterprise teams (language flexibility, streamlined IAM configuration), and the general benefits of serverless computing (scalability, pay-as-you-go, availability). It also outlines serverless/microservices best practices: treating infrastructure as code, setting up automated CI/CD pipelines, and building with monitoring and observability from day one.
  4. Starting a serverless JS project with GitLabThis post introduces a new project template for serverless JavaScript projects using the Serverless Framework, enabling users to deploy to AWS Lambda via GitLab CI/CD. It details the steps for creating the project, configuring AWS IAM users and policies, setting up CI/CD variables, and running the pipeline to deploy the function and a GitLab Pages site. It also provides an example of modifying the function to create a simple calculator.
  5. AWS Lambda usage survey resultsThis post presents the results of a survey on AWS Lambda usage habits, frameworks, testing approaches, CI/CD tools, and monitoring. It highlights the popularity of the Serverless Framework, the importance of testing in larger companies, the prevalence of AWS CloudWatch for monitoring, and the common interest in error rates. It also introduces a GitLab project template for easy integration with AWS Lambda and Serverless Framework.
  7. Announcing GitLab Serverless deploying to Cloud Run for AnthosThis post announces GitLab's support for Cloud Run for Anthos, extending its serverless capabilities to on-premise deployments. It details three flavors of Cloud Run deployment: fully managed Cloud Run, Cloud Run for Anthos on Google Cloud, and Cloud Run for Anthos on-premise. It highlights the use of GitLab CI/CD and GitLab Runners for building and deploying Knative services, and mentions upcoming support for Knative v0.9 in GitLab 12.6 and ongoing work for GKE-OP clusters.
  8. Is serverless the end of ops?This post explores the operational implications of serverless architectures, arguing that serverless does not eliminate the need for operations but rather outsources certain responsibilities. It discusses the pros (less operational overhead, scalability, lower operating costs) and cons (less control, potential security risks, unpredictable costs) of serverless. It also mentions GitLab's exploration of integrating serverless functions with Knative and Kubernetes, and supporting AWS Lambda.
  9. Run a consistent serverless platform with GitLab and KnativeThis post details the integration of GitLab with Google Cloud Run and Knative for serverless deployments. It highlights how GitLab can automatically build and deploy applications/functions as Knative services, provide endpoints, and display load/invocation metrics. It also mentions the automatic configuration of Istio-Ingress endpoints for DNS binding.
  10. Announcing GitLab ServerlessThis post announces the launch of GitLab Serverless in version 11.6, which integrates with Knative to provide serverless workload management within the GitLab UI. It highlights the benefits of serverless computing, the partnership with TriggerMesh, and provides instructions on how to activate and view serverless functions.
  11. How a fix in Go 1.9 sped up our Gitaly service by 30xThis post details how a fix in Go 1.9, specifically the switch from `fork/exec` to `posix_spawn` for process creation, significantly improved the performance of GitLab's Gitaly service. The issue was identified as increasing latency and lockups due to `syscall.ForkLock` contention, which was exacerbated by the growing virtual memory footprint of Gitaly processes over time. Recompiling Gitaly with Go 1.9 resolved this by using the more efficient `posix_spawn` syscall, resulting in a 30x reduction in latency and improved CPU utilization. The post also highlights the importance of robust monitoring (Prometheus, pprof, cAdvisor) and debugging techniques (thread dumps) in identifying and resolving such performance issues.