Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Sep 27 18:51
    jacobherrington commented #2715
  • Sep 27 18:50
    jacobherrington synchronize #2715
  • Sep 26 21:05
    ioquatix commented #2697
  • Sep 26 12:32
    byroot commented #2697
  • Sep 26 06:08
    ioquatix commented #2697
  • Sep 25 23:18

    nateberkopec on master

    Clean up and format markdown do… (compare)

  • Sep 25 23:18
    nateberkopec closed #2714
  • Sep 25 22:04
    MSP-Greg commented #2697
  • Sep 25 21:04
    MSP-Greg commented #2695
  • Sep 25 18:54
    MSP-Greg commented #2715
  • Sep 25 18:26
    jacobherrington opened #2715
  • Sep 25 17:09
    jacobherrington commented #2714
  • Sep 25 17:07
    jacobherrington synchronize #2714
  • Sep 25 17:02
    nateberkopec commented #2714
  • Sep 25 16:55
    nateberkopec closed #2713
  • Sep 25 16:55
    nateberkopec commented #2713
  • Sep 25 16:15
    jacobherrington opened #2714
  • Sep 25 15:55

    dentarg on localhost-ssl-docs


  • Sep 25 15:55

    dentarg on master

    Improve localhost SSL integrati… (compare)

  • Sep 25 15:55
    dentarg closed #2712
*for logs in regard to this
Hey, I'm having a problem with Thread.current variables being nil in the model, despite being initialized by Rails initializers. The gem in question is PublicActivity and I'm running Rails 6. I tried before_fork and on_worker_boot, but my presumption is, that Rails 6 does some threading on top of whatever server it is running on. Is that possible?
Alexander Fedulin
worker is a process, it spawns threads. That’s why setting values in before_fore/on_worker_boot gives you nils in requests
Olle Jonsson
I'm getting the hang of writing tests for Puma, it's a bit like writing tests for Python. Very concrete.
Ben Dean

I have a rails app (written by an outside company) running in Puma 3.11.4 on Ruby 2.2 (I know, sorry) and am running into all sorts of errors that I think have already been fixed in newer versions. As part of figuring out what's going on sorting out TLS problems and 100% CPU puma, our vendor tells us that it is "best practice" to not have Puma handle TLS but instead have nginx in front.

currently we have (more or less):
puma (in docker container) <---TLS port--- AWS Application Load Balancer <---TLS port------ some browser

and the vendor says that the well established best practice is:
puma (in docker container) <---TCP port--- nginx <----TLS port---- AWS Application Load Balancer <---TLS port------ some browser

because "puma isn't meant to handle TLS"

is that correct at all? I can't find anything to support it with some rudimentary searching. Also having two proxies seems like we're just asking for trouble.

I'm also just trying to update their code to use newer Puma and newer Ruby where I suspect those TLS issues will be fixed (at least from reading the CHANGELOG.md)

Blane Dabney
Yes, it's pretty standard practice for most web applications these days to allow your reverse proxy (typically nginx) to handle TLS
There's other reasons to use a reverse proxy in front of your Rails app as well
e.g. X-Accel-Redirect and send_file for having nginx handle large files directly
Ben Dean
I'm more wondering about it being best practice to not use Puma's TLS because it's "not meant for TLS" or some such thing. We have the Amazon ALB which is providing a proxy. We had been having Puma do TLS too so we didn't have unencrypted network traffic between the docker container running Puma and the load balancer (which our security guy says is required by PCI)
Seems like most of the recent Puma changes have been to fix something or other related to TLS. Seems odd that they'd spend all that effort if they really only want people to use nginx
Blane Dabney
You CAN use Puma's TLS support, it's just not considered best practices. In general, it's always been best practice to put any Rails webserver (unicorn, thin, puma, etc) behind some kind of reverse proxy, TLS or no.
Primarily, this is due to Ruby's lack of native threads and the necessity to run multiple processes to scale properly.
Jae Lee
hi, i randomly get this error : "An unhandled lowlevel error occurred. The application logs may have details." , after I googled it, it seem to point to Puma requiring "SECRET_BASE_KEY" environmental being set. i can't seem to find any info on this, what's the value supposed to be?
(alpha numeric , max length, etc )
im using Sinatra btw
not Rails so i couldn't find any more info on it
Blane Dabney
That's not a puma thing
Not that I can see. Maybe a gem or some middleware looking for it?
Quick question: Is there a best practice for how to handle connection queueing? I have a raw Puma/Rack app that sits behind an nginx load balancer, and currently, all of the queueing happens in puma. However, for reasons unrelated to queueing, I'm about to put a local nginx on the app servers, between the load balancer nginx and puma itself (it's for a flat-file caching setup). Should I just keep letting Puma queue, or should I disable that and configure the local nginx to handle the connection queueing? If so, are there any guidelines or pitfalls I should be aware of?
Blane Dabney
Hmmm beating my head against the wall. I've got a plain jRuby Rack app behind Puma that uses rack.hijack to facilitate a chunked transfer from a Java lib, and when I try to put the app behind an nginx reverse proxy, I start getting Errno::EPIPE errors, and I've tried every combination of keepalive (and no keepalive) options I can think of, and nothing helps.
Works fine without nginx, but as I'm trying to add SSL and use Rack::Sendfile to handle some flat-file operations, I'm kinda stuck.
Blane Dabney
Doesn't seem to be a rhyme or reason to exactly why it happens... though it might be the proxy timeout settings, and have nothing to do with keepalive
Blane Dabney
Yeah, I think that was it. Had my timeouts WAY too low for what this app does. Dunno why I didn't think about that.
Matthew M. Boedicker
what are the implications of running two instances of puma in the same process? one is normal rails and one is a small rack app running in a thread serving prometheus metrics
Farid Zakaria

I have a change for those that might be using Puma + JRuby; to enable Netty's OpenSSL native bindings.

I'd welcome feedback from JRuby users

Netty's OpenSSL:

Speed: In local testing, we've seen performance improvements of 3x over the JDK. GCM, which is used by the only cipher suite required by the HTTP/2 RFC, is 10-500x faster.

Julien D.
Hello there! I love Puma, this is an amazing HTTP server, thanks for all your work on that project <3. I have a quick question regarding the Puma configuration, should I use queue_requests=false if I use an AWS Elastic Load Balancer in front of it? Have a nice day all
Marwan Rabbâa
Is there a release planned with ruby 3 support ?