> For the complete documentation index, see [llms.txt](https://docs.stg.ai.neevcloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stg.ai.neevcloud.com/vm-service/faq.md).

# FAQ

This page answers the most common questions from developers and engineers deploying and operating NeevCloud VMs. Questions are grouped by topic.

***

## Understanding VM Service

<details>

<summary>What is NeevCloud VM Service?</summary>

NeevCloud VM Service lets you deploy and manage GPU and CPU virtual machines through a simple self-service experience. Unlike the GPU AI Service which runs containerized pods, VMs give you full operating system access — so you can install custom software, run background services, configure networking, and manage long-running workloads with complete control.

</details>

<details>

<summary>What is the primary purpose of VM Service?</summary>

VM Service is built for workloads that need more flexibility than a managed container environment. Primary use cases include backend services, web hosting, databases, CI/CD pipelines, containerized applications, data preprocessing, pipeline orchestration, and development environments that require persistent custom configurations. GPU VMs additionally support model training, LLM fine-tuning, and AI inference workloads.

</details>

<details>

<summary>What is the difference between VM Service and GPU AI Service?</summary>

GPU AI Service runs your workload inside a pre-configured container pod — fast to start but limited in flexibility. VM Service gives you a full virtual machine with root access, persistent environment, and the ability to run Docker, install system packages, and configure your OS. Use GPU AI Service for quick AI experiments; use VM Service when you need full control over your environment.

</details>

<details>

<summary>What is the difference between an AI template and a base OS image?</summary>

An AI template is a pre-configured Ubuntu environment with GPU drivers, CUDA, and AI frameworks already installed. Selecting a template means your VM is ready for AI workloads immediately after provisioning — no manual driver setup required. A base OS image (Ubuntu 22.04, Ubuntu 24.04, or Windows Server) is a clean installation with no pre-installed AI software. Use a base OS when you need full control over every package or when running backend services, databases, or general hosting workloads. AI templates are only available with Ubuntu OS — Windows is deployed as a vanilla base OS only.

</details>

<details>

<summary>Can I deploy a Windows VM on NeevCloud?</summary>

Yes. Windows Server is available as a base OS option when creating a VM. Select **Use Operating System → Windows Server** during VM creation. Note that AI templates are only compatible with Ubuntu — if you need an AI-ready environment with pre-installed frameworks, use Ubuntu 22.04 or Ubuntu 24.04 and select an AI template. Windows VMs are deployed as vanilla OS instances.

</details>

***

## VM Lifecycle

<details>

<summary>How do I create a VM?</summary>

From the side menu, go to **VM Service → Virtual Machines → Create VM**.

1. Choose **CPU VM** or **GPU VM** depending on your workload.
2. Select an instance configuration (Region, RAM, GPU type if applicable).
3. Enter a VM name (lowercase letters, numbers, and hyphens only; 3–50 characters).
4. Choose a pricing option: On Demand, 1 Month, 3 Months, or 12 Months.
5. Select an AI template or a base OS (Ubuntu 22.04, Ubuntu 24.04, or Windows Server).
6. Configure SSH access, networking, firewall rules, and storage.
7. Click **Deploy**. Your VM will move to **Provisioning** and then **Running** in under 20 seconds.

</details>

<details>

<summary>What is the difference between Stop, Pause, Shutdown, and Delete?</summary>

These are four different actions with very different outcomes:

* **Stop** — Immediately halts compute on your VM. Your disk and public IP are preserved. Compute billing stops; storage billing continues. Use this when you want to save cost between sessions.
* **Pause** — Suspends CPU execution while keeping the VM's memory state intact. The VM cannot accept SSH connections while paused. Use this for a brief interruption when you want to resume exactly where you left off.
* **Shutdown** — Sends a graceful ACPI shutdown signal to the operating system, allowing it to terminate processes cleanly before halting. If the OS does not respond within the timeout (around 120 seconds), the platform forces a stop. Prefer Shutdown over Stop when you have running processes that need to exit cleanly.
* **Delete** — Permanently destroys the VM and its attached ephemeral storage. Billing stops entirely. This cannot be undone — always back up your data before deleting.

</details>

<details>

<summary>How do I resume a paused VM?</summary>

From the VM list or detail page, click **Actions → Resume**. The VM transitions from Paused → Resuming → Running. Your memory state and active processes continue from exactly where they were when the VM was paused. SSH access becomes available again once the VM returns to Running state.

If host resources are unavailable at the time of resume, the operation will fail with an error — try again after a short wait.

</details>

<details>

<summary>What VM states will I see, and what do they mean?</summary>

| State         | What it means                                    |
| ------------- | ------------------------------------------------ |
| Provisioning  | VM is being created for the first time           |
| Running       | VM is active and accessible                      |
| Starting      | VM is booting after a Stop                       |
| Stopping      | VM is being halted                               |
| Stopped       | VM is off; disk persists, compute billing paused |
| Pausing       | VM is being suspended                            |
| Paused        | CPU execution suspended, memory preserved        |
| Resuming      | VM is returning from Paused state                |
| Shutting Down | OS is receiving graceful shutdown signal         |
| Deleting      | VM and storage are being permanently removed     |
| Error         | An operation failed; a retry option is shown     |

States update in real time — you do not need to refresh the page.

</details>

<details>

<summary>Can I delete a VM that is still running?</summary>

Yes, but the platform will first prompt you to confirm an automatic stop before deletion proceeds. You will also be asked to type the VM name to confirm, since deletion is permanent and cannot be undone. Ephemeral storage is deleted automatically. If you attached persistent storage, its fate depends on the retention policy you configured at creation time — it can be set to retain or delete along with the VM.

</details>

<details>

<summary>How do I delete a VM?</summary>

Select your VM in the console, click **Actions → Delete**, and confirm by typing the VM name. Deletion is permanent — the VM and its attached ephemeral disk are destroyed immediately and cannot be recovered. Persistent storage follows the retention policy set at creation.

</details>

***

## CPU VMs

<details>

<summary>What workloads are CPU VMs best suited for?</summary>

CPU VMs are designed for workloads that do not require GPU acceleration. They are well suited for:

* **Backend services and APIs** — Node.js, Python, Go, or any application server
* **Web hosting** — serving websites, WordPress, cPanel, or custom web applications
* **Databases** — running PostgreSQL, MongoDB, MySQL, or other database engines
* **Containerized applications** — Docker-based services and multi-container setups
* **CI/CD and automation** — build pipelines, test runners, and deployment automation
* **Data preprocessing** — cleaning, transforming, and preparing datasets using Pandas, Spark, or Dask
* **Pipeline orchestration** — managing ML workflows with Airflow, Prefect, or MLFlow
* **Development environments** — persistent Jupyter notebooks, experiment tracking, and debugging environments
* **Lightweight AI inference** — serving small or optimised models such as scikit-learn, LightGBM, XGBoost, or ONNX runtime

</details>

<details>

<summary>When should I choose a CPU VM instead of GPU infrastructure?</summary>

Choose a CPU VM when your workload does not involve large-scale matrix computations or deep learning model execution. CPU VMs are the right choice when you are running web servers, APIs, databases, CI/CD pipelines, or background services. They are also appropriate for AI workloads such as data preprocessing, orchestration, experiment tracking, and serving small optimised models where GPU acceleration would not provide a meaningful speed benefit. CPU VMs cost significantly less than GPU VMs, so using them for supporting infrastructure keeps your overall costs down.

</details>

<details>

<summary>What vCPU configurations are available?</summary>

Available vCPU and RAM configurations are shown on the VM creation page under the CPU VM tab. Configurations vary by region. You can filter by region using the dropdown on the instance selection page to see what is currently available in your preferred location.

</details>

<details>

<summary>Can I run Docker containers and backend services on CPU VMs?</summary>

Yes. CPU VMs give you full root access to a standard Ubuntu or Windows Server environment. You can install Docker, run multi-container applications with Docker Compose, configure systemd services, set up reverse proxies like Nginx or Caddy, and run any background daemon. If you want Docker pre-installed, add the installation commands to your startup script so the VM is ready immediately after provisioning.

</details>

<details>

<summary>Are CPU VMs suitable for CI/CD and automation workloads?</summary>

Yes. CPU VMs are a good fit for running CI/CD agents, build servers, and automation scripts. You can install tools like GitHub Actions self-hosted runners, GitLab CI runners, Jenkins agents, or any other build toolchain. Because the VM environment persists between runs, you can cache dependencies and build artifacts on disk to speed up subsequent jobs.

</details>

<details>

<summary>Can CPU VMs run AI inference workloads?</summary>

Yes, for small and optimised models. CPU VMs can serve models built with scikit-learn, LightGBM, XGBoost, ONNX Runtime, and similarly lightweight frameworks. They are also suitable for running quantised or edge-optimised models where low throughput is acceptable. For large language models, vision transformers, or any workload requiring high throughput and low latency at scale, GPU infrastructure is the appropriate choice.

</details>

<details>

<summary>When should I move from CPU VMs to GPU infrastructure?</summary>

Move to GPU infrastructure when your workload involves training deep learning models, fine-tuning large language models, running high-throughput inference on large models, or processing images and video at scale. A practical signal is runtime — if a task takes hours or days on a CPU VM that would take minutes on a GPU, it is time to switch. GPU infrastructure is also necessary when your model size exceeds what CPU memory can handle efficiently or when you need to serve many concurrent inference requests with low latency.

</details>

***

## GPU Infrastructure

<details>

<summary>When do I need a GPU VM?</summary>

Use a GPU VM for compute-heavy AI workloads — model training, LLM fine-tuning, large model inference, and generative AI. Tasks that would take days on a CPU typically complete in hours on a GPU VM.

</details>

<details>

<summary>Which GPU should I use for fine-tuning a 7B model with QLoRA?</summary>

The NVIDIA RTX A6000 (48 GB) is the best currently available option for QLoRA fine-tuning on 7B–13B models. It has more VRAM than an A100 40GB at a lower price, and it is in stock in as-south-1. If you want to spend less, use the NVIDIA A30 (24 GB) with a smaller batch size.

</details>

<details>

<summary>The GPU I want (A100, H100, H200, T4) shows 'Notify Me'. What does that mean?</summary>

It means that the GPU model is currently out of stock in the as-south-1 (Indore) region. Click **Notify Me** in the console and you will receive an alert when units become available. In the meantime, the RTX A6000 and RTX PRO 6000 Blackwell are good alternatives.

</details>

<details>

<summary>What is the difference between the RTX A6000 and the RTX PRO 6000 Blackwell?</summary>

Both are professional-grade NVIDIA GPUs. The RTX A6000 has 48 GB VRAM. The RTX PRO 6000 Blackwell is a newer architecture with 96 GB VRAM. The Blackwell is the right choice when your model or fine-tuning job requires more than 48 GB of VRAM — for example, full fine-tuning of a 34B model or running a 70B model in FP16 on a single GPU.

</details>

<details>

<summary>My training job crashes with 'CUDA out of memory'. What should I do?</summary>

This means your model + optimizer states + activations exceed the GPU's VRAM. Try these steps in order:

* Reduce batch size (`--per_device_train_batch_size` in most training scripts).
* Enable gradient checkpointing (`gradient_checkpointing=True` in your `TrainingArguments`).
* Switch from full fine-tuning to QLoRA (4-bit quantization via bitsandbytes). This cuts VRAM usage by 60–75%.
* If you still hit the limit, upgrade to a GPU with more VRAM — move from the A30 (24 GB) to the RTX A6000 (48 GB) or RTX PRO 6000 Blackwell (96 GB).

</details>

<details>

<summary>My GPU utilization shows 0–5% during training. What is wrong?</summary>

Your data pipeline is the bottleneck, not the GPU. The GPU is idle waiting for the next batch to load from disk. To fix this:

* Set `num_workers > 0` in your PyTorch DataLoader (try `num_workers=4` or `num_workers=8`).
* Add `pin_memory=True` to the DataLoader for faster CPU-to-GPU data transfer.
* Pre-tokenize and cache your dataset to disk before training so you are not running tokenization on the fly.
* If using Hugging Face Datasets, set `dataset.set_format('torch')` and cache the processed dataset.

</details>

***

## Networking & Access

<details>

<summary>What happens if I disable the Public IP toggle?</summary>

Your VM is assigned only a private internal IP and cannot be reached directly from the internet. SSH from the public internet will not work. You can still access the VM through:

* **A bastion host** — another VM in your account with a public IP that you SSH into first, then jump to the private VM from there.
* **The platform web console** — available directly from the dashboard under your VM's detail page. This works even with no public IP and no SSH key configured.
* **A VPN** — if your organisation connects to the cloud private network via VPN, you can SSH to the private IP directly from your internal network.

Disabling the public IP is the recommended approach for database VMs, internal services, and any workload that should not be exposed to the internet.

</details>

<details>

<summary>How do I access my VM if I have no public IP and no SSH key?</summary>

Use the platform web console. From the dashboard, go to your VM's detail page and click **Open Console**. This opens a browser-based terminal session through a secure backend proxy — no public IP, no SSH key, and no networking configuration required. It is the fastest recovery option if you have locked yourself out or need to troubleshoot a VM with restricted networking.

</details>

<details>

<summary>How do I set up a bastion host to access private VMs?</summary>

A bastion host is a publicly accessible VM that acts as a secure gateway to your private VMs.

1. Create one VM with **Public IP enabled** — this is your bastion host.
2. Create your other VMs with **Public IP disabled**.
3. SSH into the bastion host:

```bash
ssh -i /path/to/key.pem root@<bastion-public-ip>
```

4. From the bastion, SSH into any private VM using its internal IP:

```bash
ssh -i /path/to/key.pem root@<private-vm-internal-ip>
```

This is the standard industry practice used by AWS, GCP, and Azure for private network access.

</details>

<details>

<summary>Will my public IP change if I stop and restart my VM?</summary>

No. NeevCloud assigns sticky floating IPs — your public IP remains bound to your VM instance and does not change across stop/start cycles. This is enforced at the infrastructure level to comply with CERT-In and DOT audit log requirements. One IP is always bound to exactly one instance at any time.

</details>

<details>

<summary>I get 'Permission denied (publickey)' when SSH-ing into my VM. How do I fix it?</summary>

This almost always means one of two things: wrong key file or wrong key permissions.

```bash
# Fix permissions on your private key
chmod 400 /path/to/your-key.pem

# Confirm you are using the correct key for this VM
ssh -i /path/to/correct-key.pem root@<your-public-ip>

# Debug with verbose output to see what is happening
ssh -vvv -i /path/to/key.pem root@<your-public-ip>
```

</details>

<details>

<summary>My SSH connection keeps dropping mid-session. How do I keep jobs running?</summary>

Use tmux to detach your session from the SSH connection. The process continues running on the VM even after you disconnect.

```bash
# Start a named tmux session
tmux new -s work

# Run your process
python train.py --epochs 20

# Detach from tmux (process keeps running): Ctrl+B, then D

# Re-attach from any SSH session later
tmux attach -t work
```

</details>

<details>

<summary>How do I access a service running on my VM from my local browser?</summary>

Use SSH port forwarding to tunnel a port from the VM to your local machine without opening it publicly.

```bash
# Forward VM port 8888 to your local machine on port 8888
ssh -i /path/to/key.pem -L 8888:localhost:8888 root@<your-public-ip>

# Then open in your browser:
# http://localhost:8888
```

Alternatively, open the port in your security group rules and restrict access to your IP only. Never expose services such as JupyterLab or databases to `0.0.0.0/0` without authentication.

</details>

<details>

<summary>How do I copy files between my VM and local machine?</summary>

```bash
# Copy a single file from VM to local
scp -i /path/to/key.pem root@<public-ip>:/path/to/file ./

# Sync an entire directory (faster for many files)
rsync -avz -e 'ssh -i /path/to/key.pem' \
  root@<public-ip>:/path/to/directory/ ./local-directory/

# Upload to S3-compatible storage
aws s3 sync /path/to/directory s3://your-bucket/directory/
```

</details>

***

## Firewall & Security Groups

<details>

<summary>What are security groups and do I need to configure them?</summary>

Security groups are the firewall rules that control inbound and outbound traffic to your VM — equivalent to AWS Security Groups. Every VM requires at least one security group. By default, port 22 (SSH) is included as an inbound rule. You can add or remove rules at any time.

Inbound rules control what traffic can reach your VM. Outbound rules control what traffic your VM can send out — by default, all outbound traffic is allowed. If you are running a web server, add inbound rules for ports 80 and 443. If you are running a database, keep it private and use a bastion host or VPN for access instead of opening the port publicly.

Valid port range is 1–65535. Duplicate ports in the same rule set are not allowed.

</details>

<details>

<summary>What ports are open by default on a new VM?</summary>

Port 22 (SSH) is the only inbound port open by default. All other inbound traffic is blocked until you add rules. Outbound traffic is fully open by default — your VM can reach the internet without any additional configuration.

</details>

***

## SSH Keys

<details>

<summary>Can I save SSH keys to reuse across multiple VMs?</summary>

Yes. Go to **Account → SSH Keys** to manage your saved keys. You can add a key by pasting a public key, uploading a `.pub` file, or generating a new key pair directly in the platform. Saved keys appear in a dropdown during VM deployment so you can select them without copy-pasting each time.

Supported key types are ED25519 (recommended) and RSA-4096.

</details>

<details>

<summary>I generated an SSH key in the platform. Where do I download the private key?</summary>

Immediately after generation, the platform prompts you to download the private key as a `.pem` file. This is the only time the private key can be downloaded — it is not stored on the platform and cannot be retrieved later. If you close the prompt without downloading, you will need to generate a new key pair. Store the downloaded key securely.

</details>

<details>

<summary>Can I use a different SSH key for each VM?</summary>

Yes. During VM creation, you can select any saved key, paste a one-time public key, upload a `.pub` file, or generate a new key pair. One-time pasted keys are used only for that deployment and are not saved globally. Each VM can have a different key — there is no requirement to use the same key across your fleet.

</details>

***

## Startup Scripts

<details>

<summary>What is a startup script and when should I use one?</summary>

A startup script (Cloud Config) is a plain text script that runs automatically during the VM's first boot. Use it to automate environment setup — installing packages, setting environment variables, cloning a repository, configuring a web server, or downloading dependencies — so your VM is ready to use immediately after provisioning without manual SSH steps.

Scripts can be up to 10,000 characters. Invalid script syntax does not block deployment, but errors are logged and the script may not execute as expected. Always test your script on a running VM before baking it into a deployment.

</details>

***

## Billing & Cost

<details>

<summary>Does billing stop when I stop my VM?</summary>

Compute billing stops when your VM is in **Stopped** state. Storage billing continues because your disk persists. For example: if you stop a ₹78.38/hr RTX A6000 VM with a 200 GB disk, your hourly cost drops from ₹78.38 to approximately ₹2.32/hr (storage only) — a 97% cost reduction while preserving all your data.

</details>

<details>

<summary>If I delete my VM, does all billing stop?</summary>

Yes. Deleting a VM permanently destroys the VM and its attached storage volume. Both compute and storage billing stop immediately. However, all data on the disk is lost permanently and cannot be recovered. Always back up your data before deleting.

</details>

<details>

<summary>The monthly cost estimate in the dashboard seems very high. Why?</summary>

The monthly estimate assumes 100% uptime — that your VM runs for all 720 hours in a month. If you only use the VM for part of the day and stop it when idle, your actual compute bill will be a fraction of the displayed estimate. The estimate is a worst-case ceiling, not a prediction of your actual bill.

</details>

<details>

<summary>Should I use a Savings Plan if I am still experimenting?</summary>

No. Use on-demand pricing while you are still iterating and your runtime is unpredictable. Switch to a Savings Plan only once your workload is stable — for example, when you have a service in production running continuously, or when you know you will be running a long job for 30+ days.

</details>

***

## VM Savings Plan

<details>

<summary>What is a VM Savings Plan?</summary>

VM Savings Plan lets you move an existing On-Demand VM to a discounted pricing plan for a fixed duration, helping you reduce costs for long-running workloads.

</details>

<details>

<summary>Can I move my existing On-Demand VM to a Savings Plan?</summary>

Yes. Select **Move to savings plan** from the VM list's Actions menu or the **Pricing Plan** section on the VM details page. Your VM must be running.

</details>

<details>

<summary>Will moving to a Savings Plan interrupt my VM?</summary>

No. The tested flow allows you to change the pricing plan without recreating your VM or interrupting its running state.

</details>

<details>

<summary>Can I switch between different Savings Plan durations?</summary>

No. You cannot directly switch between active plan durations. You can extend your existing plan instead.

</details>

<details>

<summary>Can I cancel my Savings Plan early?</summary>

No. Early cancellation is not supported.

</details>

<details>

<summary>How can I extend my Savings Plan?</summary>

Open your VM's details page, go to the **Pricing Plan** section, and select **Extend** when the option becomes available. Review the extension options and payment details before confirming.

</details>

<details>

<summary>When can I extend my Savings Plan?</summary>

In the tested console, the **Extend** option became available seven days before the plan's end date.

</details>

<details>

<summary>What happens when my Savings Plan expires?</summary>

If the plan expires without being extended, the VM returns to On-Demand billing.

</details>

<details>

<summary>What if my wallet has insufficient credits?</summary>

The plan-selection flow displays an insufficient-credits warning and an **Add credits** option. Add the required credits before retrying the payment.

</details>

<details>

<summary>Are Savings Plans available for GPU AI Service instances?</summary>

No. Savings Plans are available for VM Service instances only, not GPU AI Service instances.

</details>

***

## Storage

<details>

<summary>What is the difference between ephemeral and persistent storage?</summary>

Ephemeral storage is free but deleted permanently when the VM is deleted. Persistent storage survives VM deletion — use it for databases, application data, code, and any files you cannot afford to lose. The first 100 GB of persistent storage is free; beyond that it is billed per GB.

</details>

<details>

<summary>What happens to my persistent storage if I delete my VM?</summary>

This depends on the retention policy you set when configuring persistent storage. You can choose to retain the volume (it continues to exist and billing continues) or delete it along with the VM. Ephemeral storage is always deleted when the VM is deleted, regardless of the retention setting. Always verify your retention policy before deleting a VM and back up any data you cannot afford to lose.

</details>

<details>

<summary>What is the storage limit and how is it priced?</summary>

Persistent storage can be configured between 10 GB and 2 TB, in 10 GB increments. The first 100 GB is free. Beyond 100 GB, storage is billed per GB per hour. The pricing summary panel on the VM creation page updates dynamically as you move the storage slider so you can see the cost before deploying.

Storage billing continues even when your VM is stopped — only compute billing pauses.

</details>

<details>

<summary>My disk filled up. How do I free space quickly?</summary>

```bash
# Find what is consuming the most space
du -sh /* 2>/dev/null | sort -rh | head -20

# Clear package manager cache
apt-get clean
pip cache purge

# Remove unused Docker images and containers
docker system prune -a

# Delete old log files
journalctl --vacuum-time=3d
```

</details>

***

## Templates & Environment

<details>

<summary>Which AI template should I use?</summary>

Use these guidelines:

* **Fine-tuning LLMs with LoRA/QLoRA** → Fine-Tuning template (includes PEFT, TRL, bitsandbytes)
* **Training a custom model from scratch** → PyTorch template
* **Deploying an LLM inference server** → vLLM Inference template
* **Working with Stable Diffusion, SDXL, or ControlNet** → Image Generation template
* **TensorFlow or Keras-based models** → TensorFlow template
* **Not sure** → PyTorch template (most general-purpose; install anything on top with pip)

</details>

<details>

<summary>I used a template but a package I need is missing. How do I install it?</summary>

Install it as you normally would after SSHing in:

```bash
# Python packages
pip install wandb deepspeed flash-attn

# System packages
apt-get install -y <package-name>

# To persist across reboots, add the install commands to your startup script
# or create a requirements.txt and run pip install -r requirements.txt in the startup script
```

</details>

<details>

<summary>Can I install Docker on my VM?</summary>

Yes. CPU and GPU VMs both give you full root access to a standard Ubuntu environment. You can install Docker, run multi-container applications with Docker Compose, and manage persistent volumes just as you would on any Linux server. If you want Docker pre-installed, add the installation commands to your startup script so it is ready immediately after provisioning.

</details>

<details>

<summary>nvidia-smi says 'command not found'. What is wrong?</summary>

You are on a bare OS image (Ubuntu 22.04 or 24.04) and the NVIDIA driver has not been installed. Either re-deploy using an AI template (which includes drivers), or install CUDA manually. See the Getting Started page for the full CUDA installation command sequence.

</details>

***

## Use Cases & Best Practices

<details>

<summary>What are the ideal use cases for VM Service?</summary>

**CPU VMs:**

* Backend APIs and web services with custom dependencies and persistent configuration
* Databases and data stores requiring direct OS-level access
* CI/CD pipelines, build servers, and automation workloads
* Containerized applications running Docker or Docker Compose
* Data preprocessing and pipeline orchestration for AI workflows
* Development and experimentation environments

**GPU VMs:**

* Model training and fine-tuning with full control over the environment
* LLM inference serving with custom frameworks and persistent configurations
* Generative AI applications including image, video, and code generation
* Computer vision processing at scale

</details>

<details>

<summary>What are the best practices for using VM Service?</summary>

* **Use persistent storage** for databases, application data, and code — ephemeral storage is deleted when the VM is deleted.
* **Use startup scripts** to automate environment setup so your VM is ready immediately after provisioning.
* **Use tmux or screen** for long-running processes so they continue even if your SSH session drops.
* **Stop your VM** when not in use to avoid unnecessary compute billing — storage billing continues but compute stops.
* **Save your SSH keys** in the platform under Account → SSH Keys to reuse them across deployments without copy-pasting every time.
* **Keep databases and internal services private** — disable the public IP and use a bastion host or VPN for access.

</details>

<details>

<summary>What is VM Service not suitable for?</summary>

* Simple short AI experiments where setup time matters — GPU AI Service is faster to start.
* Applications requiring guaranteed uptime with automatic failover.

</details>
