Service Management

Path: /services, /services/edit/:id

Service Management is the core page of KIOPS. From here, you can build your Git repository source code into container images, deploy to Kubernetes or Docker environments, and manage security vulnerabilities—all in one place.

Permission Notice

If you cannot access some features, please request permission from your organization administrator. Permission settings can be checked on the [Permissions] page.

---

Why Do You Need Service Management?

In modern software development, build, deploy, and security are as important as writing code. The Service Management page helps you handle all these processes from a single screen.

• Git Integration: Solves the problem of managing code across multiple repositories being cumbersome. Key benefit: Connect and manage all repositories in one place.
• Automatic Build: Solves the problem of manual build errors and time waste. Key benefit: Automatic image creation on code push.
• One-Click Deploy: Solves the problem of complex deployment commands and configurations. Key benefit: Deploy to multiple environments with a single button.
• Security Scanning: Solves the problem of discovering vulnerabilities too late. Key benefit: Detect security issues early in development.

---

Key Features

Git Repository Integration

Connect GitLab repositories using tokens, select branches or tags to work with, and configure automatic build triggers to start builds when code changes.

What is a Git Token?

A Git token (Personal Access Token) is an authentication credential for accessing the GitLab API. It is used instead of a password and allows you to grant only the necessary permissions, making it more secure. The required scopes depend on the feature level.

• Basic read operations (viewing commits/branches): minimum read_repository scope.
• Webhook registration and image push: read_api, write_repository, write_registry scopes are all required (the token's owning account must be a Maintainer or higher member of the project).

Information Available in the Source Tab

You can view Git repository information in the Source tab of the service detail page:

• Repository Connection Status: GitLab token validity and connection status.
• Branch List: All branches in the repository and the currently selected branch
• Recent Commits: Recent commit history, commit messages, and authors.
• Contributors (Last 90 Days): List of developers active within the last 90 days (sorted by commit count descending, top 5 shown. The branch configured on the repository (services.branch) is the analysis baseline).
• Language Breakdown: Programming language usage percentages in the repository.
• Tag List: Created Git tags (release versions)
• Deployed Version: Image tag and commit information of the currently deployed service (referenced in the dashboard and security analysis; [2026-05-27] new field).
• Recent Merged MRs/PRs (5 items): List of recently merged merge requests (filtered by target branch, sorted by update time descending). [2026-05-27] new.

Source Tab Layout Change

[2026-05-27] The Static Code Analysis (SAST) sub-tab was removed from the Source tab, and SAST scan results have been migrated to the Security Analysis page. The Source tab now displays repository statistics (contributors, branches, tags, deployed version) as a single screen with no sub-tabs.

Git Authentication Test

Click the Test Connection button in the Source tab to verify if the GitLab token is valid before building. This is useful for detecting token expiration or permission issues early.

Build Management

Provides build functionality to convert code into container images.

• BuildKit Build: Create container images based on Dockerfile. KIOPS has consolidated on BuildKit as the single builder.
• Build Logs: View real-time build progress.
• Build History: View and compare past build records.
• Build Settings: Configure Dockerfile path, build arguments (ARG), and image tag rules.

What is BuildKit?

BuildKit is a next-generation build tool for efficiently building container images. It offers parallel builds and superior cache performance, and lets you build images securely in Kubernetes without privilege escalation.

Deployment Management

Provides functionality to deploy built images to actual runtime environments.

• K8s Deploy: Deploy Deployment, Service, and other resources to Kubernetes clusters.
• Docker Deploy: Deploy containers directly to Docker hosts.
• Rollback: Instantly revert to previous versions when issues occur.
• Deployment History: View deployment records and compare versions.

Security Analysis

Provides security scanning features at the core of the DevSecOps pipeline. Discover and address security vulnerabilities from the early stages of development.

• SAST: Analyzes source code by running Semgrep and OpenGrep sequentially. Use after code writing or when creating PRs.
• SCA: Analyzes open source dependencies using the union of Trivy (basic) + Dependency-Check (advanced). Use when updating dependencies or before builds.
• SBOM: Analyzes software components. Use before releases or during audit preparation.
• DAST: Analyzes running applications by running ZAP + Nuclei together. Use after deploying to staging environments.

The Security Analysis page also includes IaC (Checkov), secret (Gitleaks), and security gate (OPA, comprehensive 8-area deployment decision) areas. See the Security Analysis guide for details.

What is DevSecOps?

DevSecOps is an approach that integrates Development, Security, and Operations to embed security throughout the software development lifecycle. It realizes "security from the start" rather than "security later."

---

UI Layout

Service List

The service list page presents registered services as per-GitLab-project card groups (ServiceGroupCard). Services that belong to the same project are grouped inside a single card, and each card header carries the primary action icons for that service.

Inside each card you can see the following service information.

• Service name: Unique name identifying the service.
• Git repository / default branch: Connected GitLab repository address and primary branch (main, develop, etc.).
• Build/Deploy status: Current build and deployment status (Success / Failed / Running).
• Vulnerability summary: Critical / High / Medium / Low vulnerability counts.

Card Header Action Icons

Each service card header exposes Build, Deploy, Settings, and Delete icon buttons so you can run key actions straight from the card.

Service Detail Tabs

Clicking a service takes you to the detail page. The tab layout depends on the service source type.

• GitLab-linked services: Source / Build / Deploy / Operate / Runs (5 tabs)
• Docker Hub image-based services: Image / Deploy / Operate / Runs (4 tabs; the source/build stages do not apply)

Each tab is used as follows:

• Source (GitLab only): Displays repository statistics (contributions, branches, tags, deployed version) as a single screen with no sub-tabs. Deployed Version information (current deployed commit SHA, image tag) is shown in the page header. SAST scan results have been migrated to the Security Analysis page. [2026-05-27] changed.
• Image (Docker Hub only): Select the Docker Hub image and tag to use.
• Build (GitLab only): Build settings, log viewing, build history. SCA (open source vulnerability) scan results have been migrated to the Security Analysis page (formerly the "Image Analysis" sub-tab). [2026-05-27] changed.
• Deploy: Deployment environment settings, deployment execution, deployment history.
• Operate: Opens the Operate Modal to manage the deployed service. Available tabs depend on runtime type.
  • K8s: Overview / Pod List / Deployment Management / Config/Secret / Logs / Command Execution / Domain Settings
  • Docker/Podman: Overview / Container List / Deployment Management / Logs / Command Execution / Domain Settings
• Runs: Complete pipeline execution history. Deployment information at each execution point can be tracked ([2026-05-28] new).

Where security scans live

All security scans are run and reviewed from the corresponding area tab (SAST/SCA/DAST, etc.) on the Security Analysis page. [2026-05-27] The "Static Code Analysis" (SAST), "Image Analysis" (SCA), and "Domain Analysis" (DAST) sub-tabs that previously lived inside the pipeline stage tabs were migrated to the Security Analysis page.

Source Tab Screen

Build Tab Screen

Deploy Tab Screen

Runs Tab Screen

---

How to Use

Registering a Service

This is the process of registering a new service with KIOPS.

1. Click the Add Service Button

   • Click the Add Service button at the top of the Service Management page.

2. Enter Basic Information

   • Service Name: Enter a unique name that is easily identifiable within the team. (e.g., user-api, payment-service)
   • Description: Briefly describe the role of the service.
   • Repository URL: Enter the full URL of the GitLab repository. (e.g., https://gitlab.example.com/team/project.git)

3. Enter GitLab Token

   • Enter the Personal Access Token issued from GitLab.
   • Basic reads (viewing commits/branches) require at least the read_repository scope. To also use Webhook registration and image push, the read_api, write_repository, and write_registry scopes are all required.

4. Select Branch

   • Once token authentication is complete, the branch list will be displayed.
   • Select the branch to use as default. (typically main or develop)

5. Save

   • Review all information and click the Save button.

How to Issue GitLab Token

Go to GitLab → Profile icon → Settings → Access Tokens. Set an expiration date, then select read_repository for read-only use, or read_api, write_repository, and write_registry to also use Webhook and image push.

Configuring a Build

Configure the build environment for your service. Once set up, it will be automatically applied to subsequent builds.

1. Navigate to Build Tab

   • Select the Build tab on the service detail page.

2. Open Build Settings

   • Click the Build Settings button.

3. Configure Dockerfile Settings

   • Dockerfile Path: Path relative to project root (default: ./Dockerfile)
   • Build Context: Directory containing files to use during Docker build (default: .)

4. Set Build Arguments (Optional)

   • Enter values to pass as ARG in the Dockerfile using key=value format.
   • Example: NODE_ENV=production, API_URL=https://api.example.com

5. Configure Image Tag Rules

   • Define the tag rule for built images. This rule applies only to the auto-generated image tag when the Version field is left empty.
   • Available variables: ${BRANCH}, ${SHORT_SHA}, ${TAG}, ${BUILD_NUMBER}
   • Example: ${BRANCH}-${SHORT_SHA} → main-a1b2c3d
   • ※ If the user enters the Version field, that value takes precedence over the rule above and is used as the image tag.

6. Enter Version

   • In the BuildModal Version field (formerly "Tag"), users can enter a meaningful version label (e.g., v1.2.3, release-2024-q2).
   • If left empty, a timestamp (e.g., 20260326-143000) is auto-generated. An entered version is shown in bold in the "Deployed Version" column of the dashboard and security analysis pages, visually distinguishing it from auto-generated values.
   • Format: only letters, digits, period (.), dash (-), and underscore (_) are allowed (max 128 characters). [2026-05-27] new feature.

7. Configure Registry Settings

   • Select the registry to store images. (Harbor, etc.)

8. Save

What is Build Context?

Build context determines the scope of files accessible by COPY and ADD commands in the Dockerfile during Docker build. Usually the project root (.) is used, but in monorepo structures, you can specify a specific subdirectory.

Running a Build

Execute a build for a configured service.

1. Navigate to Build Tab

   • Select the Build tab on the service detail page.

2. Click Start Build

   • Click the Start Build button.

3. Select Build Options

   • Branch/Tag: Select the source code version to build.
   • Use Cache: Choose whether to reuse layers from previous builds. Using cache reduces build time.

4. Click Start Button

   • The build starts and real-time logs are displayed.

5. Check Results

   • When the build completes, you can check the success/failure status and the generated image tag.

Reducing Build Time

• Leverage Cache: Reuse cache for unchanged layers.
• Multi-stage Builds: Exclude unnecessary build tools from the final image in the Dockerfile.
• Small Base Images: Using alpine-based images speeds up builds and deployments.

Deploying a Service

Deploy built images to runtime environments.

1. Navigate to Deploy Tab

   • Select the Deploy tab on the service detail page.

2. Select Deployment Environment

   • Choose between Kubernetes or Docker as the target environment.

3. Click Deploy Button

   • Clicking Deploy opens the deployment settings modal.

4. Configure Deployment Options

   • Namespace (K8s): Kubernetes namespace to deploy to
   • Replicas: Number of Pods to run (2 or more recommended for availability)
   • Resources: CPU/memory requests and limits.
   • Environment Variables: Environment variables to inject into the container.

5. Execute Deployment

   • Review settings and click the Execute Deployment button.

What are Replicas?

Replicas are the number of identical Pod copies. Running multiple copies means if one fails, other copies can handle requests, improving service availability. It also allows load distribution across multiple Pods.

Running a Security Scan

Analyze security vulnerabilities in your developing service. [2026-05-27] Each scan is run from the corresponding area tab on the Security Analysis page (previously run from a sub-area of the corresponding pipeline stage tab, now consolidated onto the Security Analysis page).

• SAST: Run from the SAST area of the Security Analysis page. Recommended before code commits or when creating MRs.
• SCA: Run from the SCA area of the Security Analysis page using the union of Trivy (basic) + Dependency-Check (advanced). Recommended when updating dependencies or before builds. SBOM (CycloneDX) is an independent scan, separate from SCA, run directly from the SBOM / License tab.
• DAST: Run from the DAST area of the Security Analysis page, running ZAP + Nuclei together. Recommended after deploying to a staging environment.

Click the Run button in each scan modal to start a scan. After completion you can review the severity, location, and recommended remediation for each finding.

DAST Scan Precautions

DAST simulates attacks against actual applications. Run only in test environments. Running in production environments may cause service outages or data corruption.

Managing Vulnerabilities

Review and address discovered vulnerabilities.

1. Review Vulnerability List

   • Check the list of discovered vulnerabilities in the Security tab.
   • Filter by severity to prioritize.

2. Review Detailed Information

   • Clicking a vulnerability displays detailed information:
     • Vulnerability description and CVE information.
     • Affected code location
     • Recommended remediation

3. Take Action

   • Fix: Fix the code and re-scan to confirm resolution.
   • Ignore: Mark as ignored using VEX if not exploitable in the environment.
   • Plan: Register a remediation plan if immediate fixing is difficult.

What is VEX (Vulnerability Exploitability eXchange)?

VEX is a standard format for describing the actual impact of vulnerabilities. For example, if a vulnerability is not exploitable because a specific function is not used, it can be marked as "not_affected" to reduce unnecessary alerts.

---

Auto CI Settings

Configure automatic builds and deployments when code changes. Reduce manual work and maintain consistent quality.

Automatic Build Triggers

• Branch Push: Automatic build when code is pushed to a specific branch. Use case example: Build dev environment on develop branch push.
• Tag Creation: Automatic build when a Git tag is created. Use case example: Release build on v1.0.0 tag creation.
• Specific File Changes: Build when designated files/paths are changed. Use case example: Build only on src/** changes (exclude docs).

What is CI (Continuous Integration)?

CI is a development practice where developers frequently integrate code changes and perform automated builds and tests. It helps find problems early and prevents "it works on my machine" situations.

Configuration

There is no separate "Settings" tab. The AutoCISettingsModal is opened from one of the following two entry points.

1. From the Build page

   • On the service detail page, open the Build tab and click Auto CI Settings.

2. From the service card on the list

   • On the [Service Management] list, open the action menu on the service card and choose Auto CI Settings.

3. Configure Trigger Conditions

   • Select desired trigger conditions and enter detailed values.
   • Multiple conditions can be combined.

4. Save

   • Once saved, settings are applied immediately.

Webhook environment variables

Click Manage Webhook Environments inside the Auto CI Settings modal to open the WebhookEnvConfigModal. Per-environment Webhook URL and Secret Token inspection / regeneration is performed there.

Recommended Production Settings

• develop branch: Auto build + dev environment deploy on push
• main branch: Auto build + staging environment deploy on push
• v* tags: Auto build + production environment deploy on tag creation.

Webhook Environment Management

When Auto CI is configured, a Webhook is needed for GitLab to deliver code change events to KIOPS. KIOPS automatically generates and manages Webhook URLs for each environment.

What are Webhook Environments?

Each service has 4 default environments:

• Local: Used for testing via local tunneling (ngrok, etc.) from a developer's PC.
• Dev: Used in the development server environment.
• Staging: Used in the pre-production test environment.
• Production: Used in the live service environment.

Webhook URL Structure

Webhook URLs are composed of Organization Base URL + Service Path:

• Organization Base URL: A common URL set by the organization administrator, shared across all services in the organization.
• Webhook URL: The full URL with a service-specific path appended to the Base URL.

When Base URL is Not Configured

If the organization Base URL has not been set yet, it will be shown as "Unconfigured". Please ask your organization administrator to configure the Webhook Base URL.

How to Check Webhook Settings

1. Open the Auto CI Settings modal.
2. Check the status of each environment in the Webhook Environments table at the bottom of the Settings tab.
3. Click a specific environment to view the Webhook URL and Secret Token.

Secret Token Management

• A unique Secret Token is automatically generated for each environment.
• GitLab uses this token for authentication when sending Webhook requests.
• If you need to change the token for security reasons, click the Regenerate button.

Note on Secret Token Regeneration

When a token is regenerated, the old token is immediately invalidated. You must also update the new token in GitLab's Webhook settings.

Webhook Status

• Active: The Webhook is functioning normally and has received recent events.
• Ready: Configuration is complete but no events have been received yet.
• Unconfigured: The organization Base URL is not set, so the Webhook cannot be used.
• Inactive: Manually deactivated.

---

Execution History

A page where you can view all pipeline execution records for a service at a glance. Useful for troubleshooting and performance analysis.

How to Access

Click the Runs tab on the service detail page.

Available Information

• Run Number: Unique identifier for each pipeline execution (#1, #2, ...).
• Execution Steps: Displays progress status of each step (Source, SAST, Build, SCA, Deploy, Operate, DAST) with color coding.
• Image Tag: Tag information of the built container image.
• Status: Overall pipeline execution status (Success/Running/Failed/Pending).
• Trigger: How the execution was initiated (Manual/Webhook/Scheduled).
• Start Time: When the pipeline started.
• Duration: Total time taken for pipeline execution.
• Branch: Git branch used for build/deploy.
• Commit: Git commit SHA associated with the pipeline execution (first 7 characters displayed; '-' if not webhook-triggered). [2026-05-22] new.
• Executor: User who executed the pipeline.

Detailed View

Expanding each execution record shows a timeline of individual steps. You can see the start time, end time, duration, and status of each step in detail, which is useful for finding bottlenecks or diagnosing problems.

How to Use Execution History

• Build Time Trend Analysis: Check if build times are gradually increasing.
• Failure Pattern Identification: Analyze if failures frequently occur at specific steps.
• Deployment History Tracking: Audit when, who, and which version was deployed.

---

Operational Features (OperateModal)

Perform real-time operational tasks on deployed services. Provides tools for quick response when issues occur.

Log Viewing

1. Open Operate Modal

   • Click the Operate button in the service list.

2. Select Logs Tab

   • Select the Logs tab in the modal.

3. Configure Log Options

   • Container: Select the container to view (if multiple)
   • Line Count: Number of log lines to display (100, 500, 1000, etc.)
   • Live: Automatically display new logs.
   • Filter: Show only logs containing specific keywords.

4. Download Logs

   • Download log files as needed.

Container Restart

1. Select Restart Tab in Operate Modal

2. Select Restart Target

   • Select the container or Pod to restart.

3. Execute Restart

   • Click the Restart button and monitor progress.

Restart Precautions

Restarting may cause temporary service interruption. For zero-downtime restarts, maintain 2 or more replicas and use rolling updates.

Resource Monitoring

View real-time container resource usage. (Requires Metrics Server)

• CPU: CPU utilization (%). Watch when consistently above 80%.
• Memory: Memory usage. Watch for risk of OOM when approaching limits.

Metrics Server Required

To use resource monitoring features, Metrics Server must be installed on the Kubernetes cluster. You can install it from the Monitoring tab on the [Runtime Environments] page.

Remote Command Execution

Use the Command Execution tab of the Operate Modal to run commands against containers/Pods. Interactive shells (kubectl exec -it, docker exec -it, attach, port-forward) are not supported; only one-shot or streaming command modes are available, with limits on concurrent sessions and output size.

Security Warning

All command execution activity is recorded in audit logs. Use only when absolutely necessary in production environments, and prefer log viewing or monitoring tools first.

Instant Rollback

If issues occur after deployment, click the Instant Rollback button in the Deployment Management tab to revert to the immediately previous revision (K8s only). There is no dedicated rollback tab, and choosing a specific revision is not supported — only a single rollback to the previous revision.

Rollback Notes

Instant Rollback rolls a Kubernetes Deployment back to the previous revision (--to-revision is not specified). Triggering it again right afterward will move further back one more revision.

HPA Management (Auto Scaling)

Manage HPA (Horizontal Pod Autoscaler) which automatically adjusts Pod count based on traffic (K8s only). There is no dedicated HPA tab — HPA is managed from the HPA section inside the Pod List tab.

• Minimum Replicas (minReplicas)
• Maximum Replicas (maxReplicas)
• CPU Threshold (targetCPU, %)

KIOPS supports only simple CPU-based HPA. Memory/custom metrics, multiple metrics, and scaling policies are not provided.

Metrics Server Required

Metrics Server must be installed for HPA to function properly. You can check Metrics Server status in the HPA section, and an install button appears if it is not installed.

---

Deployed-Version Tracking

Overview

[2026-05-22] Deployed-version tracking lets you see the exact code and image information of the currently deployed service at a glance. SAST scan results are re-evaluated against the deployed code to accurately assess the security risk of the actual deployment state.

Display Locations

• The "Deployed Version" column of the dashboard [Service Status] table
• The security analysis page header ("Currently deployed version:")
• The Source tab header of the service detail page
• The pipeline execution records list of the Runs tab

Displayed Information

• Image tag (user-entered version or auto-generated timestamp)
• Deployment time
• Deployed commit SHA (first 7 characters)
• Deployed image URL

User-entered versions are shown in bold for visual distinction.

Risk Matching

• SAST scan results are recalculated against the deployed commit.
• If the scanned commit differs from the deployed commit, a "Previous Commit" label is shown to warn of a code version mismatch.
• When no deployment information is available, "No Match" is displayed.

---

Build/Repository Statistics

Get an overview of service development and build status at a glance.

Build Statistics

• Total Builds: Total number of build executions. Use to understand development activity level.
• Build Success Rate: Percentage of successful builds. Below 90% needs improvement.
• Average Build Time: Average time per build. Consider optimization if over 5 minutes.
• Recent Builds: Recent build list. Use to check latest changes.

Repository Statistics

• Total Commits: Total number of commits.
• Active Branches: Number of currently active branches.
• Contributors (Last 90 Days): List of developers active within the last 90 days (top 5 shown by commit count. The branch configured on the repository is the analysis target; default_branch if unset).
• Recent Merged MRs/PRs (5 items): List of recently merged Merge Requests/Pull Requests (filtered by target branch, sorted by update time descending).
• Analyzed Branch: The Git branch on which contributor, recent-activity, and MR statistics were aggregated (services.branch value; default_branch if unset).
• Recent Commits: Recent commit list.

---

Glossary

If you encounter unfamiliar terms, check here.

• Microservice: An architecture that composes applications from small, independently deployable service units.
• Container Image: An immutable filesystem packaging an application and its execution environment.
• Registry: A repository for storing and distributing container images (Harbor, Docker Hub, etc.).
• Dockerfile: A text file containing commands for building a container image.
• Tag: A label attached to a specific commit in Git, typically used to mark release versions.
• Rolling Update: A method of gradually deploying new versions without service interruption.

---

Notes

Security-Related Precautions

• DAST scans should only be run in test environments. Running in production environments may affect services.
• Operational tasks (log viewing, Shell access, etc.) are all recorded in audit logs.

Data Retention Policy

• Git tokens are encrypted and stored securely.
• Build logs are automatically deleted after a certain period.
• Download and preserve important logs in advance.