Creating a queue

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

Console
API
CLI
Go

Open Queues and select Create queue.
Enter a Name. Enable FIFO queue if processing must be ordered within each message group. The console adds .fifo to the name.
Set Visibility timeout, Retention, Delivery delay, and Receive wait in seconds.
Optionally choose a Dead-letter queue of the same type and set the maximum receive count. Create the destination queue first.
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.

Send this request to https://queue.sa-saopaulo-1.basaltic.sh using the headers described in Authentication.

POST /v1/queues
Content-Type: application/json

{
  "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.

Save the JSON request from the API tab as request-1.json. Use your configured account and region.

basaltic queue queue create --from-file request-1.json

Save the JSON request from the API tab as request-1.json. Configure credentials, account, and region through the SDK environment variables.

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)
	}
}

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.

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 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, configure dead-letter handling, and watch queue metrics for backlog growth and repeated receives.

Get started

Products

Platform

Help

Create a standard or FIFO queue

Naming and type

Settings and defaults

Encryption and later changes

Next steps

​Create a standard or FIFO queue

​Naming and type

​Settings and defaults

​Encryption and later changes

​Next steps

Create a standard or FIFO queue

Naming and type

Settings and defaults

Encryption and later changes

Next steps