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

Deployable Naming Convention

I believe a natural extension to the existing branch-specific deployment is to add pattern matching. Given a pattern, such as deploy/* or [deploy]*, all branches meeting that criteria will pass. In doing so, developers can easily deploy staging/*, release/*, support/*, d-feature/* without interruption to workflow or cluttering deployments with all branches.

Accordingly, patterned context names would come before branch-specific names so they can be overridden if necessary. Also, similar to branch-specific deploys, a subdomain equivalent to the star would aid accessibility.



    command = "build command" 

Then, ideally:

My Use Case

In my particular use case, hundreds of collaborator branches may be generated at any given time. Though only a subset of these may require deployment. Being able to add a tag or naming convention enables me to isolate only functional changes.

Prior Inquiry

  1. Automatically deploy branches that match name pattern
  2. Branch Name Pattern Matching

@tcardlab, we do have an open feature request for this and we’ll post an update if/when this feature becomes a reality.


It would be great to be able to quickly see the monthly Build minutes consumed per site.
This would help to quickly identify which sites need to be optimised to reduce total Build minutes.


Hey Jinksi! That’s a really great question - we have an open feature request for this we are working on, as we understand this is a very realistic use case. Thanks for pointing it out!

I will post an update and follow up with you once we have a timeline for this! :muscle:

1 Like

On the DNS page, I would like to be able to set up a set for Google Mail with one click, instead of having manually to enter the five lines of MX information. Namecheap offers this and it’s wonderful.

1 Like

It would be neat to be able to set up catch-all forwarding e-mail address for each site, although that probably would require a server intercepting MX calls. I don’t think this is possible with DNS alone.

DNSSEC is urgently a must.


hi @BayuAngora - we’re already tracking requests for this! We know many people in the community are excited about us implementing DNSSEC. We will update things here as soon as we have anything to share :slight_smile:

1 Like

I would love Rust support. There are multiple static site generators like Cobalt and Zola. Why Rust is better than Node? Cause its fun. I like writing Rust and writing my website in it would be good practice.

Assuming your build process is to clone the entire repo to a jenkins machine and run the build command, the easiest way to achieve this would be to just install cargo on the jenkins VMs. Might need some file access protections and to revoke syscall privileges I dunno. You don’t need to cache common crates until people are building rust generators regularly.

Can I help in any way?

In the same vein, I would LOVE the ability to pull data from Netlify’s Analytics dashboard via a simple API endpoint. I’ve been itching to provide users with insight into “trending” or “most popular” content on our Gatsby site.

There’s a ton of value-add from this in our particular case… achieving this in a way closely integrated with Netlify would be a dream come true.

1 Like

Hey Robert! You can absolutely help us get Rust into our build image. PR’s gladly accepted, here: https://github.com/netlify/build-image . Oh, there already is one for rust (https://github.com/netlify/build-image/pull/320), so I’ll ping our dev team to see if we can get that prioritized.

Our build process is described here for your edification: https://www.netlify.com/blog/2016/10/18/how-our-build-bots-build-sites/

Heya @toddbirchard! Good feature suggestion, but we don’t currently have plans to create API endpoints for analytics. Nonetheless, I’ve added your voice to the open feature request so we can let you (and this thread) know if we do end up shipping it.

1 Like

With the new build time limits and billing, it would be great to have a costs / usage breakdown per site instead of per account to be able to charge clients accordingly without having to create new accounts for every client.

1 Like

are you thinking along the same lines as @Jinksi here? if yes, we have a feat request already!

(…i guess its time i pruned this thread a bit to make it easier to follow along…)


Yep, sorry! Totally missed that.

Is the a way to set a global Time Zone per account?
For example, to properly understand “Function log”.
I use 24h format, not am/pm.

That log is not currently changeable. It is only for the past 1 hour, so you can guess if it is AM or PM though :slight_smile:

It would be marvelous if you could control Snippets from the netlify.toml file. For me, this would be much more convenient, and it would all editing instead of the current delete-and-replace.

It would be great if the input fields for environment variables would be bigger (or could expand), especially the value fields. We use the Netlify API to create them, but the way we use it in combination with GatsbyJS, we need to create single values that are JSON strings that can become quite long. Editing existing environment values for apps is something we do surprisingly often, and it would be very helpful if the web interface would allow us to do this more easily instead of us having to scroll inside a tiny input field or having to open up a separate text editor to copy paste it to and fro just to be able to see more text at once.

Would like to add my weigh in to DNSSEC please!