Skip to content

Create an instance

View as Markdown

Create a TIR Instance from a pre-built or Base OS image. You choose the image and the plan it runs on, decide how to pay for it, and set up its workspace, storage, network access, and start scripts. Most choices have a sensible default, so for a first instance you can launch with only an image and a plan. To launch from your own container image instead, see Create an instance from your own image.

  • A TIR project, and a role in it that lets you create instances. An OWNER, ADMIN, TEAM LEAD, PROJECT MANAGER, or PROJECT LEAD can create them; a MEMBER needs a policy that allows it.
  • On a prepaid account, enough credit for the launch: about 24 hours of the plan’s hourly price for On-Demand, or the full price of the term for a committed plan.
  • (Optional) An SSH key in your TIR SSH Keys, if you want to connect over SSH. TIR keeps its own keys, separate from MyAccount’s, so add your key in TIR even if it is already in MyAccount. You can also add one on the form. See SSH Key Management.
  • (Optional) A dataset, a Shared File System, or, in Delhi, a Parallel File System, if you want to mount one when the instance starts. See TIR Object Storage, TIR Block Storage, TIR Shared File System, and Parallel File System.
  • (Optional) A TIR private cluster, to run the instance on your own cluster. See TIR Private Cluster.

In TIR, open your project. In the side menu, under Compute, select Containers (Instances), and then select Create Instance. You can also create instances with the TIR API.

There are three kinds of image. To find one by name, type in Search Image.

  • Pre-built images are maintained by E2E. Each comes with a machine learning framework and an app. Most open JupyterLab, and the ComfyUI and FramePack images open their own app instead. Start here if you want to work in your browser straight away. The list changes over time. For each image’s versions, with its Python, CUDA, and Ubuntu, see Pre-built images and their versions.
  • Base OS images are plain operating-system images that you reach over SSH, so the form asks for an SSH key and a security group.
  • Custom Images are your own images from your project’s Container Registry, including images you saved from another instance. The tab also takes a public image from a registry such as Docker Hub. See Create an instance from your own image.

Each image starts on its first version. To use another, choose it from the image’s list. You can still change the version in Version at the top of the form, or pick another image with Change image.

Some image versions run only on CPU plans or only on GPU plans, and the form offers only the plans that the chosen version supports. If no plan supports it, choose another version.

TIR suggests an Instance Name of instance- followed by the date and time. Keep it, or type your own. A name is up to 50 characters of letters, digits, hyphens, and underscores, starts with a letter, and ends with a letter or digit. Each instance in a project needs its own name.

Under Select Computing Resource, run the instance on a GPU plan, a CPU plan, a Spot plan, or your own private cluster.

Choose a GPU by the memory your model needs, such as NVIDIA H200 SXM with 141 GB, then pick a size under Configuration. An instance has from one to eight GPUs.

These are the GPU plans on sale. The list changes as E2E adds and retires plans.

GPU Memory per GPU vCPUs per GPU RAM per GPU GPUs per instance in Delhi GPUs per instance in Chennai
B200 180 GB 26 375 GB Not offered 1, 2, 4, or 8
H200 141 GB 28 375 GB 1, 2, 4, or 8 8, committed plans only
H100 80 GB 26 250 GB 1, 2, 4, or 8 1, 2, 4, or 8
A100 80 GB 80 GB 16 115 GB 1, 2, or 4 Not offered
A100 40 GB 40 GB 16 115 GB 1, 2, 4, or 8 Not offered
L40S 48 GB 60 220 GB 1, 2, or 4 Not offered
L4 24 GB 25 110 GB 1, 2, 4, or 8 Not offered
V100 32 GB 8 120 GB 1, 2, or 4 Not offered

A size’s vCPUs and RAM grow with its number of GPUs: a two-GPU H100 size has 52 vCPUs and 500 GB of RAM. For an eight-GPU H200 or H100 size, TIR suggests a Private Cluster instead.

CPU plans are the C3 series. Its sizes are the same in both regions. The smallest has 4 vCPUs with 8 GB of RAM, and the largest 48 vCPUs with 256 GB. In between are 8 vCPUs with 16 GB, 16 with 32 GB, 20 with 64 GB, 24 with 96 GB, 32 with 128 GB, and 40 with 192 GB.

A Spot Instance runs on spare GPU capacity at a lower hourly price. Spot plans come in H200 and H100, such as Spot H200, with one, two, four, or eight GPUs. A Spot H200 size has 30 vCPUs per GPU.

TIR can stop a Spot Instance at any time, without warning, to take the capacity back. It emails you once the instance has stopped. Choose Spot for work that can be interrupted and picked up again, such as training that saves checkpoints to /home/jovyan. For what to do after TIR stops one, see What happens when TIR takes back a Spot Instance?

On Private Cluster, choose one of your project’s TIR private clusters to run the instance on. You pay for the cluster as a whole, so the cluster’s charge covers every instance on it, and a launch on it skips the credit check.

You can launch only on a plan that is in stock. A GPU marked Inventory not available, or a size marked Plan not available, is out of stock right now. Try another GPU, another tab, or the other region, or come back later.

Under Instance Pricing, choose how the size is billed. If the term you want is not listed, select Show more pricing.

  • On-Demand is billed by the minute at the plan’s hourly rate, from when the instance reaches Running until you stop or delete it. Start here when you are unsure how long you need the instance.
  • A committed term, such as 1 Month Savings Plan or 1 Year Savings Plan, costs less than On-Demand and is charged in full upfront, once for the whole term. Terms differ by plan and run from seven to 1,095 days. Choose one for an instance you will keep running for the whole term.
  • On the Spot Instances tab, every plan is billed On-Demand, at its Spot rate, for the minutes it runs.

Every instance launches on a paid plan. For prices, see E2E Networks pricing. For how each option works over time, see Billing options for TIR Instances.

When you choose a committed term, you confirm it in Committed Plan Confirmation as you launch:

  1. Tick the acknowledgement that TIR charges the full price of the term upfront and does not refund unused days.
  2. Choose what happens when the term ends. Auto renewal of the same committed plan is the default; the other choices move the instance to hourly billing at the plan’s On-Demand rate, or delete the instance.
  3. Select Proceed.

The term starts, and its price is deducted, when the instance first reaches Running. A committed instance stays running for its whole term. You can restart it, and you can delete it during the term, though the remaining days are not refunded.

The workspace is the instance’s disk, mounted at /home/jovyan. Files there stay through restarts, stops, and starts, so keep your code, notebooks, and data in it. Everything else in the container goes back to the image’s contents when the container restarts.

The workspace is 30 GB unless you change it, and it takes any size from 30 GB to 15,000 GB. Set it with the slider in steps of 10 GB, or type any whole number of GB. Choose a size that holds your data, models, and checkpoints. The FramePack image needs a workspace of at least 50 GB.

The first 30 GB of workspace are free. Each GB above that has a monthly price and is charged for the hours the workspace exists, whether the instance is running or stopped. You can make the workspace larger later, and each increase is permanent; see Increase the workspace size.

(Optional) To encrypt the workspace with AES-256, turn on Workspace Encryption. You can set it only here, when you create the instance.

(Optional) Under Other storage, mount a Shared File System and Datasets, and in Delhi a Parallel File System, on the instance. If you have none yet, each has a link to create one.

  • Datasets you select are mounted under /datasets, each at /datasets/ followed by its name.
  • A Shared File System or Parallel File System needs a mount path. The path starts with /, uses only letters, digits, hyphens, and underscores between single slashes, and ends in one of those characters. Pick a path other than /home/jovyan, /mnt/local, /datasets, or a path under /datasets/.
  • A Parallel File System can be mounted Read Only.

Their data lives in that storage, outside the instance, so it stays when the instance restarts or is deleted. You can also mount them later; see Mount datasets and file systems.

To connect over SSH, pick one or more of your SSH keys under SSH Keys, or add a new key in Add SSH Key. The list holds only your own keys; a teammate who needs to log in adds their own key to the instance later. An image you reach only over SSH, such as a Base OS image, needs at least one SSH key. If you skip SSH now, you can turn it on later; see Connect to an instance over SSH.

An instance with an SSH key also needs a security group that opens port 22. If you leave it empty, the instance gets the project’s default security group, Default-SSH-Security-Group, which allows SSH on port 22 from any address and is fixed. While SSH keys are selected, only groups that open port 22 can be chosen.

The ports open on the instance are the ports in the inbound rules of its security groups. To reach an app you run on another port, see Open a port on an instance.

(Optional) Under Reserve IP Address, pick one of the project’s free reserved IPs in Select IP address, or use the link under the list to reserve a new one. A reserved IP keeps its address across stops and starts, and it is billed on its own. Otherwise, an instance with SSH keys or open security group ports gets a public IP from E2E’s pool, and that address can change after the instance stops and starts again.

To reach one of your VPCs privately, attach a VPC IP after the instance is created. For both, see Manage IP addresses on an instance.

Under Advanced Settings, you can also:

  • (Optional) Under Startup Script, pick saved scripts that run each time the instance starts or restarts, or select Create a new Script. A start script is one way to install your packages again after each restart. See Run start scripts on an instance.
  • (Optional) Under Add-Ons, pick Tensorboard on port 6006 or Gradio on port 7860. TIR gives each one a web address, so you can open the app you run on that port. Add-ons work only on images with JupyterLab, and you can add them later too. See Use TensorBoard on an instance and Use Gradio on an instance.

Select Launch Instance. If anything is missing, such as the image version, the computing resource, or a security group for your SSH key, TIR names it so you can fill it in. If your account still needs to finish its customer validation, TIR asks for your billing details first; complete them, then launch.

If the launch is refused for credit or because the plan ran out of stock, see Troubleshooting TIR Instances, which names each message and what to do.

The new instance is Waiting in Manage Instances while TIR finds a host with the plan’s free CPU, memory, and GPUs, downloads the image, and starts it. On a pre-built image this takes about two minutes. When the status changes to Running, the instance is ready, and only then does billing for the plan start.

If the instance stays on Waiting, open it and read Instances Event, which lists the container’s recent events and says what it is waiting for; see The instance stays on Waiting.

Once the instance is Running, open JupyterLab from its App URL, or connect over SSH if you added a key. On a GPU instance, run nvidia-smi in a terminal or a notebook cell. It lists each GPU the plan gives you, with its memory and the CUDA Version its driver supports.

Your new instance is ready for work. To use the same data across instances, keep it on a dataset or a file system you mount on the instance. To keep the packages you install across restarts, save the instance as an image or run start scripts on an instance. To watch its GPU, CPU, and memory use, see Monitor an instance.