> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scitix.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Create General Service

> Create continuously running HTTP applications, tool APIs, or custom container services in Siverse, and verify service access.

General Service is used to deploy continuously running HTTP applications, tool APIs, and custom container services. It provides resource, port, gateway, Health Check, and version management. To deploy model engines and multi-role inference workloads, see [Create an LLM Inference Service](/siverse/inference/create-llm-inference-services.md).

## Prerequisites

* You have obtained the required permissions and quota for the target Region, Cluster, Project Group, and resource pool.
* You have prepared a fixed-version image, startup command, application port, and minimal validation request.
* Persistent data has been planned for an authorized Volume, and external dependencies and authentication methods have been confirmed.
* For stateful applications, you have assessed multiple replicas, parallel operation of new and old versions, and data schema compatibility.

## 1. Go to the Create page

1. Go to **Inference > General Service**.
2. Select **Region**, **Cluster**, and **Project Group**.
3. Click **Create**.

## 2. Enter configuration information

### Basic information

| Configuration Item | Description |
| - | - |
| **Region**, **Cluster**, **Project Group** | Determine the service ownership and collaboration scope. |
| **Service Name** | The unique name of the service. |
| **Version Name** | The workload version name, used to distinguish between different versions of the service. |
| **Public within Project Group** | Controls whether the service is visible within the project group. |

### Resource Information

The total resources required by the service are calculated based on the specifications of each replica and the number of replicas.

| Configuration Item | Description |
| - | - |
| **Replicas** | Number of service instance replicas. |
| **Resource Type** | Select a resource type, such as reserved, on-demand, or Spot. |
| **Instance** | Select the instance specification used by the service. When using a reserved instance, first select a resource pool. |
| **Count Per Node** | Configure the number of instance specifications used by a single replica. |
| **Resource Priority** | Controls the service scheduling priority. |

### Environment Information

The cmd and mount configuration use paths inside the container.

| Configuration Item | Description |
| - | - |
| **Port Configuration** | Configure the ports on which the service listens. You can add multiple ports. The ports must match the ports actually listened on by the application. |
| **Image** | Select a preset image, a custom image, or enter an image address. Using an image with a fixed version is recommended to ensure reproducibility during subsequent rollbacks. |
| **cmd** | The command to run after the container starts. |
| **Storage** | Mount the volumes required for service operation. Store persistent data in volumes to prevent data loss when instances are rebuilt. |
| **Environment Variables** | The platform injects variables into the container runtime environment when the workload starts. Applications can read the configuration at runtime, avoiding hardcoding configuration in the code. |

The application must listen on an address accessible from outside the container. If it listens only on `127.0.0.1`, it typically cannot be accessed through the gateway.

### Enhanced Features

| Configuration Item | Description |
| - | - |
| **Require Authentication** | <ul><li>When enabled, the platform generates an access token for the service. Go to the **Overview** tab on the service details page, click **View Details** under **Endpoint**, and then view it in **Endpoint Details**.</li><li>When calling the service, include `Authorization` in the request header. Anonymous access will be denied.</li><li>Authentication is recommended for production services.</li></ul> |
| **Enable Base URL** | <ul><li>Enabled: The access entry retains the prefix path generated by the platform, and the service must be able to handle this prefix path.</li><li>Disabled: The entry path is rewritten, and the service processes requests according to its original API path.</li><li>To support prefix paths, configure `root_path` or `basePath` in the application framework, or use a custom Nginx rewrite to forward requests to the application's original path.</li></ul> |
| **Graceful Exit Delay** | Configures the wait time before the service stops, allowing the instance time to process pending requests, release connections, or save its state. |
| **Health Check** | <ul><li>Allow sufficient time for initialization to prevent repeated restarts during startup.</li><li>A failed liveness probe triggers an instance restart. A failed readiness probe removes the instance from traffic but does not restart it.</li><li>Supports **Exec**, **HTTPGet**, and **TCPSocket**. To check multiple ports simultaneously, use **Exec** to run a custom check command, and ensure that the image includes `nc` or an alternative tool.</li></ul> |

### Gateway Configuration

General services are accessible through the platform's shared gateway by default. To use a custom domain name or configure different ingress paths by port, click **Add Gateway** and select **Independent Gateway**.

Before configuring an independent gateway, complete the following preparations:

* Resolve the custom domain name to the gateway ingress of the current cluster.
* Prepare the domain certificate and HTTPS access policy.
* In **Port Configuration**, add the service ports that the standalone gateway needs to forward.

| Configuration Item | Description |
| - | - |
| **Domain Name** | Enter a custom domain name for which DNS resolution and HTTPS have been configured. |
| **Dir** | Configure the path used by callers, such as `/api` or `/metrics`. Within the same cluster, the combination of domain name and entry path must be unique. |

The same domain name can be forwarded to different ports through different entry paths, or separate domain names can be configured for different ports. The gateway configuration should be consistent with the service's actual protocol, port, path, authentication method, and **Base URL** settings.

### Monitor Information

Used to compare error rates, latency, and resource usage before and after release.

| Configuration Item | Description |
| - | - |
| **Metrics Monitor** | When enabled, the platform collects service metrics for monitoring, capacity analysis, or alerting. |
| **Metrics Port** | The port on which the service exposes Metrics, for example, `9090`. |
| **Metrics Dir** | The path on which the service exposes Metrics, for example, `/metrics`. |

## 3. Submit Creation

Click **Create**. After submission, view the Status in the general service list.

When the service has not entered **Running**, view the workload details, events, image pull status, storage mounts, and startup logs to confirm that the instance is ready.

## 4. Verify Access

After the service enters **Running**, follow these steps to verify that the access path and service responses meet expectations:

1. Go to the **Overview** tab on the service details page. Under **Endpoint**, click **View Details**. In **Endpoint Information Details**, view link addresses such as **Shared Gateway** and **In-Cluster Access (VPC)** by port. If authentication is enabled for the service, also obtain the platform-generated token.
2. Send a minimal request based on the actual protocol, port, entry path, and authentication method. If multiple ports are configured for the service, verify each port that needs to be exposed externally. When authentication is enabled, include `Authorization` in the request header. When **Base URL** is enabled, confirm that the service can process request paths with a prefix.
3. Confirm that the required volume read/write operations, external dependencies, and authentication flow are functioning properly.
4. Record the error rate, latency, and resource usage as a baseline for comparison during subsequent updates or canary releases.

> [!NOTE]
>
> Passing the Health Check only indicates that the platform probe has succeeded; it does not guarantee that service requests will succeed. Route production traffic only after the expected ready capacity has been reached and minimum request validation has passed.

## Next Actions

After the service passes the initial verification, you can continue with the following actions based on subsequent objectives:

* **Release or roll back a service version**: Low-risk, validated changes can be released directly. When the target version needs to be validated first, use canary release and, based on the validation results, continue the rollout, roll back, or clean up the old version. For more information, see [Release and Roll Back General Services](/siverse/inference/release-and-rollback-general-inference-services.md).
* **Manage running services**: View service Endpoints and workloads, or as needed, update the dedicated gateway, bring services online or offline, restart services, configure scheduled policies, share, or Delete services. For more information, see [Manage General Services](/siverse/inference/manage-general-inference-services.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.