If the creation of the file is streamable, then you don't need to wait 60 seconds before starting the download. Just send the file to the user as you are generating it, saving up to 60 seconds to your users.

This would apply to many processes such as encryption, compression, video conversion, etc. A problematic case would be the one where you have to process the whole file in order to know which would be its first bytes (for instance if the format of the file requires to specify either its length or its hash). If this is your case, see if there is a way to circumvent the limitation.

Note that in some cases, you'll even be able to specify the size of the file before sending it to the user (and if you can do it, it's a very nice feature, in order for the web browser to show the progress bar while downloading the file). For instance, many encryption algorithms return as many bytes as the input, making it straightforward to determine the actual size of the resulting file.

Otherwise, the HTTP POST which starts processing the file should return just an ID which makes it possible to track the progression of the first stage. Once the first stage is finished and the file can be downloaded, another route should make it possible to download the file using the original ID. This can be used easily with AJAX polling to let the user wait before downloading the file, and then present him with a download link.

and emails the file upon success/failure

Please, don't do that. In most cases, the first time you'll send an email containing an 600 MB attachment would be the last time the user will use your app.

If the creation of the file is progressive, then you don't need to wait 60 seconds before starting the download. Just send the file to the user as you are generating it, saving up to 60 seconds to your users.

This would apply to many processes such as encryption, compression, video conversion, etc. A problematic case would be the one where you have to process the whole file in order to know which would be its first bytes (for instance if the format of the file requires to specify either its length or its hash). If this is your case, see if there is a way to circumvent the limitation.

Note that in some cases, you'll even be able to specify the size of the file before sending it to the user (and if you can do it, it's a very nice feature, in order for the web browser to show the progress bar while downloading the file). For instance, many encryption algorithms return as many bytes as the input, making it straightforward to determine the actual size of the resulting file.

Otherwise, the HTTP POST which starts processing the file should return just an ID which makes it possible to track the progression of the first stage. Once the first stage is finished and the file can be downloaded, another route should make it possible to download the file using the original ID. This can be used easily with AJAX polling to let the user wait before downloading the file, and then present him with a download link.