RabbitMQ destination configuration lacks support for specifying a custom vhost, and the server URL validation is overly restrictive (requires a dot in the hostname).

[cesarmartin]

Describe the bug
RabbitMQ destination configuration lacks support for specifying a custom vhost, and the server URL validation is overly restrictive (requires a dot in the hostname).

To Reproduce
Steps to reproduce the behavior:

1. Go to Outpost and create a new RabbitMQ destination
2. Try to enter server URL as rabbitmq:5672 (Docker service name)
3. Observe that the validation fails - it only accepts formats like rabbitmq.local:5672 (requires a dot in hostname)
4. Successfully configure with rabbitmq.local:5672 using /etc/hosts workaround
5. Attempt to specify a custom vhost (e.g., /my-vhost or /production)
6. Notice there is no field or option to configure the RabbitMQ vhost
7. Connection defaults to the / (default) vhost with no way to change it

Expected behavior

1. Server URL validation should accept valid hostnames without dots (e.g., rabbitmq:5672 for Docker service names, localhost:5672, etc.)
2. A "Virtual Host" field should be available in the RabbitMQ destination configuration to specify which vhost to connect to
3. Alternatively, support vhost in connection string format or via environment variables

Additional context

• Environment: Docker Compose setup with RabbitMQ and Outpost in the same network
• Use case: Need to separate webhook streams by environment (dev/staging/prod) using different RabbitMQ vhosts
• Current workaround: Using /etc/hosts mapping (e.g., 127.0.0.1 rabbitmq.local) which is not ideal for production deployments
• Impact: This limitation blocks production deployment where vhost isolation is essential for security and organization
• RabbitMQ vhosts are a standard feature for multi-tenancy and environment separation, and most RabbitMQ clients support vhost configuration

This affects anyone trying to:

• Use Docker service discovery without external DNS
• Deploy in environments with multiple RabbitMQ vhosts
• Implement proper isolation between different webhook streams or tenants

Thanks for the great work on Outpost! 🙌

[alexluong]

Hi there, thanks for checking out Outpost and sharing your feedback.

Your suggestion makes sense but I'm curious if you can elaborate more on your use case of Outpost? Initially, our assumption is that Outpost is used for outbound events where destinations are from end-users (users of Outpost operators) and therefore the use case you mentioned was fully fleshed out. Would love to hear more about your use case to learn more and make sure our implementation would work for you.