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

# Creating a queue

> Choose queue type, visibility, retention, and a dead-letter destination.

Create a queue in the account and region used by its producers and consumers.
A queue name and type are permanent. Its timing settings can be updated later.

## Create a standard or FIFO queue

<Tabs>
  <Tab title="Console">
    1. Open **Queues** and select **Create queue**.
    2. Enter a **Name**. Enable **FIFO queue** if processing must be ordered
       within each message group. The console adds `.fifo` to the name.
    3. Set **Visibility timeout**, **Retention**, **Delivery delay**, and
       **Receive wait** in seconds.
    4. Optionally choose a **Dead-letter queue** of the same type and set the
       maximum receive count. Create the destination queue first.
    5. Add optional **Tags**, then select **Create queue**.

    The console opens the queue page. Use **Metrics** for depth and traffic
    charts, and **Messages** to inspect queued messages.
  </Tab>

  <Tab title="API">
    Send this request to `https://queue.sa-saopaulo-1.basaltic.sh` using the
    headers described in [Authentication](/authentication).

    ```http theme={null}
    POST /v1/queues
    Content-Type: application/json
    ```

    ```json theme={null}
    {
      "name": "order-workers",
      "visibility_timeout_seconds": 60,
      "message_retention_seconds": 345600,
      "receive_wait_time_seconds": 20,
      "redrive_policy": {
        "dead_letter_queue": "failed-orders",
        "max_receive_count": 5
      },
      "tags": { "environment": "production" }
    }
    ```

    Create `failed-orders` first, or omit the redrive policy. HTTP `201`
    returns the queue in `queue`. Save its ID for message operations and its
    CRN for IAM policies. A name ending in `.fifo` creates a FIFO queue.
  </Tab>

  <Tab title="CLI">
    Save the JSON request from the API tab as `request-1.json`. Use your configured account and region.

    ```bash theme={null}
    basaltic queue queue create --from-file request-1.json
    ```
  </Tab>

  <Tab title="Go">
    Save the JSON request from the API tab as `request-1.json`. Configure credentials, account, and region through the SDK environment variables.

    ```go theme={null}
    package main

    import (
    	"context"
    	"encoding/json"
    	"fmt"
    	"os"

    	basaltic "github.com/basaltic-sh/sdk-go"
    	"github.com/basaltic-sh/sdk-go/queue"
    )

    func readJSON(path string, value any) error {
    	data, err := os.ReadFile(path)
    	if err != nil {
    		return err
    	}
    	return json.Unmarshal(data, value)
    }

    func run() error {
    	ctx := context.Background()
    	cfg, err := basaltic.NewConfig(ctx)
    	if err != nil {
    		return err
    	}
    	client := queue.New(cfg)
    	var request1 queue.CreateQueueRequest
    	if err := readJSON("request-1.json", &request1); err != nil {
    		return err
    	}
    	result1, err := client.CreateQueue(ctx, &request1)
    	if err != nil {
    		return err
    	}
    	fmt.Printf("%+v\n", result1)
    	return nil
    }

    func main() {
    	if err := run(); err != nil {
    		fmt.Fprintln(os.Stderr, err)
    		os.Exit(1)
    	}
    }
    ```
  </Tab>
</Tabs>

## Naming and type

Names contain 1–80 ASCII letters, digits, dots, dashes, or underscores and
start with a letter or digit. The `.fifo` suffix counts toward the limit.
Names are unique within an account and region. UUID names and the `crn:`
prefix are reserved.

Use standard queues when consumers can tolerate best-effort ordering. Use FIFO
when messages for the same group must be processed in order. Neither choice
removes the need for idempotent processing after a lease expires. See
[FIFO and dead-letter queues](/queue/fifo-and-dead-letter-queues).

## Settings and defaults

| Setting | Default | Allowed range |
| - | - | - |
| `visibility_timeout_seconds` | 30 | 0–43,200 seconds |
| `message_retention_seconds` | 345,600 (4 days) | 60–1,209,600 seconds (14 days) |
| `max_message_bytes` | 262,144 (256 KiB) | 1,024–262,144 bytes |
| `delay_seconds` | 0 | 0–900 seconds |
| `receive_wait_time_seconds` | 0 | 0–20 seconds |
| `kms_data_key_reuse_period_seconds` | 300 | 60–86,400 seconds |
| `content_based_deduplication` | `false` | FIFO only |
| Redrive `max_receive_count` | Required when attaching a target | 1–1,000 |

Choose visibility long enough for typical processing, then extend individual
leases for longer work. Retention bounds how long unacknowledged messages
remain. A delay postpones first availability. Long polling lets receives wait
for work instead of repeatedly returning empty.

The message-size limit counts the body and attributes together. A smaller
limit can catch unexpectedly large producer requests before they are stored.
The API exposes message-size and KMS settings that are not in the console's
creation form.

## Encryption and later changes

Bodies and attributes are encrypted at rest. Omit `kms_key` for platform
management, or provide a customer KMS key name, UUID, or CRN through the API.
Responses return a `kms_key` resource reference. Follow
[Queue permissions](/queue/permissions) for the grants needed to bind a key.

Update settings with `PATCH /v1/queues/{queue_id}`. Omitted fields stay as they
are. `kms_key: null` restores platform encryption for future messages;
existing messages retain their original encryption key. Keep that key usable
until those messages have been consumed or expired. `redrive_policy: null`
removes the dead-letter policy.

## Next steps

[Send and consume messages](/queue/messages), configure
[dead-letter handling](/queue/fifo-and-dead-letter-queues), and watch
[queue metrics](/queue#metrics) for backlog growth and repeated receives.


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