# Launch your first server
Source: https://docs.quake.ai/docs/quickstart/launch-your-first-server
Markdown: https://docs.quake.ai/docs/quickstart/launch-your-first-server.md
> The fundamentals path: launch a Developer-plan instance on Quake AI, open the right ports, and serve a public web page over SSH in about 30 minutes.
---
# Launch your first server
This is the fundamentals path of the [Quickstart](/docs/quickstart): the honest IaaS on-ramp every other learning path builds on. The walkthrough takes about 30 minutes and uses a public web server as the working example. By the end, you'll have a running server on the public internet serving a page you wrote yourself, plus a working understanding of how the platform fits together.
This walkthrough launches a single `s1a.micro` instance (1 vCPU, 1 GiB RAM) on the `PublicEphemeral` network, which assigns a public IP at boot with no floating IP add-on. See [Resource tiers](/docs/account/resource-tiers) for upgrade paths if you outgrow it.
## Prerequisites
You need a Quake AI account with a project and a resource tier picked. If you have not done that yet, work through [Get started](/docs/quickstart#get-started) at the top of the Quickstart first.
The walkthrough has five steps:
1. Set up a secure login from your computer to your server.
2. Configure your project's firewall to allow login and web traffic.
3. Launch a server.
4. Connect to the server, install web-server software, and publish a page.
5. Delete the server when you're done (optional).
To follow along, you'll need:
- A web browser and a terminal on your computer (macOS, Linux, or WSL on Windows).
- About 30 minutes. Most of that is the server starting up and the web-server software installing.
You can follow the walkthrough through Quake AI's browser interface (the default), the command line, or OpenTofu (Terraform) code. From step 2 onward, each step has tabs for all three. Pick one and stay with it for the rest of the walkthrough.
If you work with an AI coding assistant, you can reach the same result by driving it instead: see [How to provision a server with an AI agent](/resources/ai-assisted-development/quickstart-with-ai-agent).
The final step is optional. A running server uses your project's resources (a CPU core, memory, a public IP address) and stays reachable from the internet for as long as it's up. Step 5 walks through deleting the server when you're ready to clean up. If you want to keep the server running and experiment further, skip the final step.
The bash commands below assume macOS, Linux, or WSL. If you are on Windows, [set up a Linux CLI environment](/docs/tools/windows-cli-environment) first. WSL 2 is the recommended option.
## 1. Add an SSH key
SSH (Secure Shell) is the standard protocol for logging into a Linux server from your terminal. Quake AI authenticates SSH with a key pair: a public key you upload to your project and a private key that stays on your workstation. SSH never transmits the private key over the network. See [Key pairs](/docs/compute/concepts/key-pairs) for more.
Upload the public key (`~/.ssh/id_ed25519.pub`) to your project. Name the key after the workstation that holds the private key. `my-laptop`, your hostname, or your username are all common choices. You will reuse this key for every server you create, so pick a name you will recognize later.
1. In the portal, go to **Compute** > **Key Pairs** and select **Create Keypair**.
2. In the dialog that opens, switch to the **Import Keypair** tab.
3. Provide a name (for example, `my-laptop`).
4. Paste the contents of `~/.ssh/id_ed25519.pub` into the **Public Key** field.
5. Select **OK**.
Verify your key appears in the **Key Pairs** list before continuing.
## 2. Create a security group
A security group is a virtual firewall attached to your instance's network port. Each rule allows specific inbound (ingress) or outbound (egress) traffic by protocol, port range, and source address. Every project includes a `default` security group that allows traffic only between its own members, so an instance using only `default` is unreachable from the internet. Create a dedicated group that opens TCP port 22 (SSH) and TCP port 80 (HTTP), then select it instead of `default` when you launch the server in step 3. See [Security groups](/docs/network/concepts/security-groups) for more.
1. In the portal, go to **Network** > **Security Groups** > **Create Security Group**.
2. Name the group `web-access`. The Description field is optional.
3. After saving, open the group and select **Create Rule**.
4. From the **Protocol** dropdown, select **SSH**. The dialog auto-fills **Direction** to `Ingress` and **Ether Type** to `IPv4`. The SSH preset implies port 22 and hides the **Port Type** and **Port** fields, so you do not set them. Leave **Source** at its default `All Traffic` (which resolves to `0.0.0.0/0`).
5. Save the rule.
6. Select **Create Rule** again. From the **Protocol** dropdown, select **Custom TCP Rule** and set **Port** to `80`. Leave **Direction** at `Ingress`, **Ether Type** at `IPv4`, and **Source** at `All Traffic`.
7. Save the rule.
8. Confirm the group has both rules listed (TCP/22 and TCP/80) before continuing.
```bash
openstack security group create web-access \
--description "SSH and HTTP access"
openstack security group rule create web-access \
--ingress --protocol tcp --dst-port 22 --remote-ip 0.0.0.0/0
openstack security group rule create web-access \
--ingress --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0
```
The Terraform path defines the security group inline alongside the instance in [step 3](#3-launch-your-first-server). Skip ahead.
For production, restrict the SSH rule's **Source** (CLI flag `--remote-ip`) to your workstation's public address instead of leaving the default `All Traffic` (`0.0.0.0/0`). Port 80 stays open to the internet because you're running a public web server.
## 3. Launch your first server
Launch a virtual machine on the **PublicEphemeral** network. Instances on this network receive a public IP directly, so SSH and HTTP work as soon as the instance reaches **Active** status.
PublicEphemeral is the shortest path to a public IP because the address binds directly to the instance's network port. Deleting the instance also releases the IP. That fits a quickstart, where you create, view, and delete the server in the same session. Do not use this pattern for production projects.
For a real project, run the instance on a private network behind a router and associate a **floating IP** from the **PublicStatic** pool. The floating IP persists when you rebuild the VM, and you can detach and reattach it across instances. See [Create a VM on a private network](/docs/compute/how-to/create-vm-private-network) for that walkthrough.
The wizard opens with three tabs (`Base Config`, `Network Config`, `System Config`); the `Confirm Config` tab appears once the first three tabs validate. Advance with the **Next:** button at the bottom of each tab.
#### Base Config
1. Select **Compute** > **Instances** > **Create Instance**.
2. Name the instance `web-01` and choose an availability zone (for example, `us-east-1a`).
3. Pick the `s1a.micro` flavor under **Shared Resources** (1 vCPU, 1 GiB RAM, the Developer-plan footprint).
4. Select an image (`Ubuntu-24.04` is a good first choice) and set a disk size of at least 20 GiB. Check **Deleted with the instance** so the platform removes the disk when you delete the instance later.
#### Network Config
1. Select **Next: Network Config**.
2. From the network list, select **PublicEphemeral**.
3. In the security groups list, **select `web-access`** (the group created in step 2). The wizard does not pre-select the project's `default` group; selecting `web-access` applies the rules you created in step 2 and is enough on its own to allow inbound SSH and HTTP.
#### System Config
1. Select **Next: System Config**.
2. Choose **Keypair** as the login type.
3. Select the `my-laptop` keypair you uploaded in step 1.
#### Confirm Config
1. Select **Next: Confirm Config** and review the summary.
2. Select **Confirm** to launch.
The instance moves from **Build** to **Active** within a minute.
#### Connect
In the Instances list, copy the public address shown in the **Fixed IP** column for `web-01` (PublicEphemeral attaches the public address directly to the instance's port, so it appears as the fixed IP rather than as a separate floating IP). Then from your local terminal:
```bash
ssh ubuntu@INSTANCE_IP
```
Replace `INSTANCE_IP` with the address from the Instances list. Type `yes` to accept the host key. Your prompt changes to `ubuntu@web-01`, confirming the server is up and reachable.
The CLI path requires the OpenStack client and a sourced credentials file.
1. Install the OpenStack client following [Install the OpenStack client](/docs/tools/install-openstack-client).
2. [Generate app credentials](/docs/tools/generate-app-credentials) and download `openrc.sh`.
3. Source the file in your shell:
```bash
source ~/path/to/openrc.sh
```
4. Verify the connection:
```bash
openstack token issue
```
A successful response returns a token with your project ID, user ID, and expiration time.
Launch the instance on **PublicEphemeral**:
Wait for the server to reach `ACTIVE` status, then look up its public address:
```bash
openstack server show web-01 -c status -c addresses
```
Then connect from your local terminal:
```bash
ssh ubuntu@INSTANCE_IP
```
Replace `INSTANCE_IP` with the address from the previous command's output. Type `yes` to accept the host key. Your prompt changes to `ubuntu@web-01`.
The IaC path uses [OpenTofu](https://opentofu.org/), the open-source fork of Terraform. The `tofu` and `terraform` commands accept identical configuration; this tab uses `tofu`.
1. [Install OpenTofu](https://opentofu.org/docs/intro/install/).
2. [Generate app credentials](/docs/tools/generate-app-credentials) and download `openrc.sh`.
3. Source the file in your shell:
```bash
source ~/path/to/openrc.sh
```
Create a working directory and add `main.tf`:
```hcl
terraform {
required_version = ">= 1.6.0"
required_providers {
openstack = {
source = "terraform-provider-openstack/openstack"
version = "~> 2.0"
}
}
}
provider "openstack" {}
data "openstack_images_image_v2" "ubuntu_24_04" {
name = "Ubuntu-24.04"
most_recent = true
}
data "openstack_networking_network_v2" "public" {
name = "PublicEphemeral"
}
resource "openstack_compute_keypair_v2" "my_laptop" {
name = "my-laptop"
public_key = file("~/.ssh/id_ed25519.pub")
}
resource "openstack_networking_secgroup_v2" "web_access" {
name = "web-access"
description = "SSH and HTTP access"
}
resource "openstack_networking_secgroup_rule_v2" "web_access_22" {
direction = "ingress"
ethertype = "IPv4"
protocol = "tcp"
port_range_min = 22
port_range_max = 22
remote_ip_prefix = "0.0.0.0/0"
security_group_id = openstack_networking_secgroup_v2.web_access.id
}
resource "openstack_networking_secgroup_rule_v2" "web_access_80" {
direction = "ingress"
ethertype = "IPv4"
protocol = "tcp"
port_range_min = 80
port_range_max = 80
remote_ip_prefix = "0.0.0.0/0"
security_group_id = openstack_networking_secgroup_v2.web_access.id
}
resource "openstack_networking_port_v2" "web_01" {
name = "web-01-port"
network_id = data.openstack_networking_network_v2.public.id
security_group_ids = [openstack_networking_secgroup_v2.web_access.id]
}
resource "openstack_compute_instance_v2" "web_01" {
name = "web-01"
flavor_name = "s1a.micro"
key_pair = openstack_compute_keypair_v2.my_laptop.name
block_device {
uuid = data.openstack_images_image_v2.ubuntu_24_04.id
source_type = "image"
destination_type = "volume"
volume_size = 20
boot_index = 0
delete_on_termination = true
}
network {
port = openstack_networking_port_v2.web_01.id
}
}
output "instance_address" {
value = openstack_compute_instance_v2.web_01.network[0].fixed_ip_v4
}
```
The `block_device` block creates a 20 GiB volume from the Ubuntu-24.04 image and boots the instance from it. Attach security groups to the Neutron port with `security_group_ids`, not to the instance by name. See [Authoring IaC templates](/docs/automation/concepts/authoring-iac-templates) for the full pattern. Quake AI's `s1a.micro` flavor has zero ephemeral disk and boots only from a volume (see the [Block Storage](/docs/block/concepts/volumes) concept for more on volume-backed instances).
Initialize and apply:
```bash
tofu init
tofu apply
```
OpenTofu prints the instance's public address as the `instance_address` output. Connect from your local terminal:
```bash
ssh ubuntu@INSTANCE_IP
```
Replace `INSTANCE_IP` with the value of `instance_address`. Type `yes` to accept the host key. Your prompt changes to `ubuntu@web-01`.
## 4. Serve a page
You are logged in to `web-01` as `ubuntu` over SSH. Install nginx, write a page, and visit it from your browser.
Install nginx:
```bash
sudo apt update
sudo apt install -y nginx
```
Ubuntu starts nginx automatically. nginx is already serving its default welcome page on port 80.
Replace the default page with your own greeting (substitute your name):
```bash
echo '
Hello from Alex on Quake AI
' | sudo tee /var/www/html/index.html
```
Open `http://INSTANCE_IP` in your browser (substitute the public IP you used to SSH in). The greeting renders. nginx is serving the page from the Quake AI VM you provisioned and configured in this walkthrough.
To publish the same site on a domain you own, [point your domain at the instance's public address](/docs/network/how-to/point-domain-to-quake-ai) before you add [TLS with Let's Encrypt](/docs/network/how-to/lets-encrypt-certificate) or [a CDN in front](/docs/network/how-to/front-with-cdn).
Disconnect from the server:
```bash
exit
```
## 5. Clean up
A public web server should not run unattended. Delete the instance now that you have seen the page. You can reuse the SSH key (`my-laptop`) and the security group (`web-access`); leave them in place for the next server you launch.
1. In the portal, go to **Compute** > **Instances**.
2. Find the `web-01` row, open the Settings (gear) icon, and select **Delete**.
3. Confirm the deletion. The instance disappears from the list within a few seconds.
4. Verify `web-01` is no longer in the Instances list before closing the page.
The Console delete-instance dialog has no option to delete attached volumes. The **Deleted with the instance** checkbox you set when creating the instance controls whether the platform removes the boot volume; the delete dialog does not. Boot volumes created by the instance wizard show no name in **Storage** > **Volumes** (the Name column renders `-`), so the Console cannot match a leftover boot volume by name. Identify it by its **Available** status and creation time, or read the volume ID from the CLI or API.
```bash
openstack server delete web-01
```
Verify the instance is gone:
```bash
openstack server list
```
```bash
tofu destroy
```
OpenTofu prints the destruction plan and asks for confirmation. Type `yes`. OpenTofu removes every resource declared in `main.tf`, including the key pair and security group. If you want to keep the key pair and security group for future use, run the Console or CLI deletion instead.
You provisioned a public web server, viewed it in a browser, and deleted it. The same workflow extends to more complex projects: more instances, custom images, automation, self-managed reverse proxies, Kubernetes clusters. Where to go next:
- [How to point a domain at a Quake AI resource](/docs/network/how-to/point-domain-to-quake-ai): map a hostname at your registrar to a floating IP or public address.
- [How to issue and auto-renew a TLS certificate with Let's Encrypt](/docs/network/how-to/lets-encrypt-certificate): HTTPS on the VM you built.
- [How to put a CDN in front of a Quake AI workload](/docs/network/how-to/front-with-cdn): cache static assets at the edge after DNS is set.
- [Compute concepts](/docs/compute/concepts/): instances, flavors, images, and how the platform models them.
- [Quickstart learning paths](/docs/quickstart): static sites, databases, containerized apps, object storage, and infrastructure as code.
- [Access & Credentials](/docs/tools/): full CLI setup, app credentials, API tokens, and credential rotation.
- [Automation how-tos](/docs/automation/how-to/): IaC patterns, CI integration, and template usage.
- [Platform overview](/docs/platform/): what Quake AI is, what it runs on, and how it differs from other providers.
