you need to set the auth headers. here is my echo setup for connecting to reverb:

 configureEcho({
    broadcaster: "reverb",
    key: config.public.reverbAppKey,
    wsHost: config.public.reverbHost,
    wsPort: config.public.reverbPort,
    wssPort: config.public.reverbPort,
    //force TLS if browser is https
    forceTLS: (window.location.protocol === 'https:'),
    // forceTLS: (import.meta.env.VITE_REVERB_SCHEME ?? 'https') === 'https',
    enabledTransports: ['ws', 'wss'],
    authEndpoint: config.public.apiBase + '/broadcasting/auth',
    auth: {
      headers: {
        Authorization: "Bearer " + token.value
      },
    }
  });

you need to set the auth headers. here is my echo setup for connecting to reverb:

 configureEcho({
    broadcaster: "reverb",
    key: config.public.reverbAppKey,
    wsHost: config.public.reverbHost,
    wsPort: config.public.reverbPort,
    wssPort: config.public.reverbPort,
    //force TLS if browser is https
    forceTLS: (window.location.protocol === 'https:'),
    // forceTLS: (import.meta.env.VITE_REVERB_SCHEME ?? 'https') === 'https',
    enabledTransports: ['ws', 'wss'],
    authEndpoint: config.public.apiBase + '/broadcasting/auth',
    auth: {
      headers: {
        Authorization: "Bearer " + token.value
      },
    }
  });

the only cpanel setup for redis i believe is https://docs.cpanel.net/ea4/containers/redis-via-containers/

but if you have root access to the server, you can just do a standard redis install. or use a free redis hosting (like upstash) if your site is not super caching heavy and you aren't able to manage the service yourself and able to troubleshoot any service issues that may arise.

the only cpanel setup for redis i believe is https://docs.cpanel.net/ea4/containers/redis-via-containers/

but if you have root access to the server, you can just do a standard redis install. or use a free redis hosting (like upstash) if your site is not super caching heavy and you aren't able to manage the service yourself and able to troubleshoot any service issues that may arise.

I had this same issue a long time ago...

In short... it is because you are using a pooled connection.

In long... Database migrations often fail on a pooled connection because connection poolers are designed for short, stateless transactions, while migrations require long-running, stateful connections and exclusive access to the database schema. Also some connection poolers use a transaction-based pooling mode (like transaction_mode in Supavisor/PgBouncer). In this mode, a client gets a connection for the duration of a single transaction. Migrations, however, often run multiple commands in sequence that require session-level state to persist between queries, which breaks the pooler's assumptions.

My recommendation is creating a second connection in your app, and put the non-pooled connection string in it. then in your migrations put $connection = '...your second connection...' so they will utilize that while the rest of your app uses the pooled connection.

My fix was i actually hooked into the events and checked for when a migration is running and i dynamically changed the connection on the fly

I had this same issue a long time ago...

In short... it is because you are using a pooled connection.

In long... Database migrations often fail on a pooled connection because connection poolers are designed for short, stateless transactions, while migrations require long-running, stateful connections and exclusive access to the database schema. Also some connection poolers use a transaction-based pooling mode (like transaction_mode in Supavisor/PgBouncer). In this mode, a client gets a connection for the duration of a single transaction. Migrations, however, often run multiple commands in sequence that require session-level state to persist between queries, which breaks the pooler's assumptions.

My recommendation is creating a second connection in your app, and put the non-pooled connection string in it. then in your migrations put $connection = '...your second connection...' so they will utilize that while the rest of your app uses the pooled connection.

My fix was i actually hooked into the events and checked for when a migration is running and i dynamically changed the connection on the fly

the purpose of these is more about concurrency, not latency. 15ms is pretty good execution time for laravel locally. and external will add latency as it has a longer path to travel. if you are using swoole it is to allow more simultaneous requests to be handled. you can go from tens or hundreds of requests per second on PHP-FPM, to thousands of requests per second on the same hardware using swoole or frankenphp. it looks like you are just misunderstanding the purpose of the framework

the purpose of these is more about concurrency, not latency. 15ms is pretty good execution time for laravel locally. and external will add latency as it has a longer path to travel. if you are using swoole it is to allow more simultaneous requests to be handled. you can go from tens or hundreds of requests per second on PHP-FPM, to thousands of requests per second on the same hardware using swoole or frankenphp. it looks like you are just misunderstanding the purpose of the framework