Feature requests - what do you already love, what could be better?

I would love to see an automatic HTML, CSS and JavaScript minifier upon deployment. I am aware the there is a third party HTML minifier available as an add-on but it would be nice to see this as a native Netlify feature.


Hi @dk-raw,

We already have Post Processing that does this: https://app.netlify.com/sites/<site-name>/settings/deploys#asset-optimization.

I’m not sure if you’re talking about this as an add-on. It’s a native Netlify feature.

1 Like

Thanks for replying so quickly. I guess the I did not scour through the settings that firmly.
Once again, thank you for your service.

I would love to see or have some way to download detailed verbose build log when build failed.

File-based configuration for Deploy Notifications

I recently set up a bunch of different environments for a few clients’ websites on their accounts and one of the most tedious parts of it was having to copy/paste some of the site configuration settings from one site to another.

A perfect example of this is deploy notifications. On every site we set up, we want both Slack and webhook notifications for three events (deploy started, failed, succeeded). The endpoint URLs are the same for every single one. That’s six copy-and-pastes per site, multiplied by many sites. I’d much rather this be a part of our boilerplate netlify.toml. G-d forbid one of those URLs should change some day and we’d have to do this … a hundred times over :scream:

Basically netlify.toml is awesome but I want it to do more so we don’t have to copy/paste things into an admin panel. Any plans to include this? Thanks!

1 Like

hi there @mfan, that’s an intersting idea! i have forwarded it on to the relevant team, if we end up implementing something like this i will definitely let you know.

1 Like

Conditional deploy notifications

HI, we currently have two sources of triggering a build: Github and hooks from our CMS. The deploy succeeded notifcations are triggered after each succesful deploy (as they should).

However we have some (resource intensive) activities that only need to take place after a build hook from the CMS has been triggered. We would like to be able to configure a deploy notification that is triggered ONLY when the build has been inititated by a certain hook. In this way, the intensive task is not executed on code only changes from github.

Keep up the good work :wave:t2:

Hey there, @redmagic :wave:

Thanks so much for taking the time to write this up! I have shared your idea with the product team.

Happy building :netliconfetti:

Different levels for Environment Variables the same way Vercel is doing it. This way we can use the same env name but set different values based on development, preview, or production.


Hey there, @cbauc :wave:

Thanks so much for reaching out and sharing this feedback with us. I have shared your request with our Product team.

It would be nice to be able to view logs for function deploy previews (not deployment logs, but runtime logs).

I’ve come across cases where my code works fine when run locally (even executing Netlify dev), but it throws errors upon publishing it. On those cases there is no way to view the logs without commiting my current code to git and then checking the logs for the branch deploy. And as you know, it’s not very good to commit code you know is failing…

Hey @edgar,

You can check function logs for deploy previews. There’s an option in the UI to filter the logs:

Is that not working?

I would love the option to add 301 redirects for trailing slashes. Specifically a global rule to configure either:

I’m aware there are many different support threads already with discussions on this issue as well as a request for documentation clarity, which I’m not trying to repeat. Ultimately it is not currently supported and only workarounds are offered.

The advice seems to either boil down to

  1. change your site directory structure to match your preferred trailing slash convention (e.g. /page.html for no trailing slash and /page/index.html for a trailing slash) and make sure pretty URLs are enabled.
  2. use canonical URLs.

For Pretty URLs, I feel like the convention of trailing-slash-for-directory and no-trailing-slash-for-file convention is a bit outdated and I would prefer to configure this without changing my app build settings. As for canonical URLs - I already use them, but I have never encountered an SEO team who don’t demand both canonical URLs and 301 redirects for dealing with duplicate content.

I’d love to hear if there are any plans to implement a feature like this, given the traction it gets in the support forum? I really enjoy using Netlify :netliheart: for my side projects but this is one of those little feature gaps that holds me back from using it for bigger projects.

Hey there, @aileen-r :wave:

Thank you so much for taking the time to write up this detailed feedback and share it with us. We take feedback seriously to drive improvements, so we really appreciate all insights! I have shared this directly with the Product team.

Unfortunately, I cannot offer insights into future plans today. Do know it is on folks radar, and that feedback like this helps move the needle :slight_smile:

1 Like

I don’t know if this would be possible but this feature would give more granularity in the way we manage access by countries.

This would for instance work for US Embargoes sanctions (CRIMEA - REGION OF UKRAINE, CUBA, IRAN, NORTH KOREA, and SYRIA).

Right now netlify accept only ISO 3166-1 alpha-2. Redirect options | Netlify Docs

Using this kind of contition would help a lot :

  # Embargoes compliance.
 conditions = {Country = ["CU", "IR", "KP", "SY", "UA-43"]}
  from = "/*"
  to = "/restricted"
  status = 302
  force = true

With the code UA-43 the restriction would be apply only to the Crimea and not the whole Ukraine.

Thanks for the awesome work you do :slight_smile:

1 Like

hey there, @slumbering :wave:

Thanks for reaching out and sharing some details and examples with this-- we appreciate it! I have sent your feedback directly to our Product team.

1 Like

I get a lot of PRs from dependabot, etc. I’d love for netlify to only build those PR’s deploy previews if requested by an (authorized) human user clicking a link in the PR thread.

This often happens in OSS accounts, and can quickly lead to overages.

I could imagine netlify holding a user-configurable denylist of github usernames, defaulting to dependabot, github-actions, snyk, and a few other common ones. If the PR was opened by one of the denylist users, the netlify github app would comment in the PR thread with a link which, when clicked by an authorized user, would offer the choice to run the build. This would be similar to how builds by unauthorized users work now

thanks for suggesting that, benny. i’ve passed your feedback to the product team for this idea.

1 Like

Previews should work on every branch not just merge to main – or be triggable easily via some bot command on git.

We use a stacked diff workflow i.e. a chain of branches and so we can’t previews on anything beyond the first branch.

Hey @MichaelrMentele,

Thank you so much for the insight. We’ve passed it on to the relevant team.