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

Since the certificate is issued just to us based on DNS settings, and we don’t have any intention of supplying you with the necessary secret that our system generated to use the certificate, we don’t have any plans to allow export. You can of course fetch your own certificate from lets encrypt by DNS challenge, even at the same time ours is valid :slight_smile:

1 Like

4 posts were split to a new topic: API feature requests

If only Netlify could also deploy managed Hasura (https://hasura.io/) so that we can deploy apps with database with a great degree of flexibility!

2 Likes

Hook into dynamodb and send email via ses without needing to use your own aws account, just like Netlify
Functions.

2 Likes

The ability to host a database alongside functions.

Potentially Postgres, or a NoSQL db(?)

I feel this would give users a completed stack across the platform.

4 Likes

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.

Example

netlify.toml

[context.'deploy/*']
    command = "build command" 

Then, ideally:
whatever-*-is.myDomain.com

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
11 Likes

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

5 Likes

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.

Hi there,

I’ve got a number of sites that initially failed to build due to CMS configuration. It was fast and easy to get them up and running but as a result each of these sites just has a small white thumbnail with “not found” in unreadable text in the thumbnail.

Based on this thread, I know that screenshots are only taken initially or not at all. I’m actually confused why “not found” is displayed instead of the placeholder image. Is this a bug?

Otherwise, would it be possible to add a small “take a screenshot” button to the individual site overview dashboard? For situations when screenshots fail to capture or undesirable screenshots are captured, this would provide an easy way to address the problem.

Thanks!

Hi there,

I really like branch deploys and how we can specify https://${branch}--${project}.netlify.com, would it be possible to add support for tag deploys too? It’d be really cool for versioning, like if my tag was v0.0.1 I could access it at https://v0-0-1--${project}.netlify.com. I realized projects like Material UI have a separate mirrored repository to work around this.

Thanks!

1 Like

HTTP3 support for Netlify. This would make Netlify sites load faster, especially on constrained and poor quality networks.

According to Googles tests, HTTP3 reduces average page load time between 8% - 13%, with poorer network connections receiving the most benefit.

HTTP3 support already exists for Cloudflare, Google Chrome, and Mozilla Firefox.


5 Likes

I would love a form builder, similar to Google Forms. We use HTML forms too, and that’s been working great, but we also send client feedback forms all the time, and writing them in HTML would take way to long so we end up using Google Forms. It’d be a bit more professional if we were able to do these forms on our own domain without the Google Forms branding.

4 Likes

that’s an interesting idea, @zowpowow! Ill share that with the team for sure!

Netlify Analytics recently received a new geography view allowing you to see which country is driving the most traffic. This is a good first step. For us it would be much more useful if you could split up the traffic by city though. Would like to submit this as a feature suggestion.

2 Likes

Hey Janosh, thanks for suggesting this. We might consider this for the future! I’ve added a note on the analytics project, and we’ll respond here if there are any updates to share. :slight_smile:

1 Like

Thanks @perry, much appreciated!

1 Like

Would it be possible to have one branch do multiple deploys?

For example: Netlify is linked to a Github repo. All code is merged into the master branch of that repo. The Netlify config for that repo has two different URLs - example.com and either staging.example.com or just use a consistent netlify url for staging.

The deploys to the main site can be locked just like normal, but the deploys to the staging branch are continuous.

Why?

  • All code is merged to master, reducing merge conflicts and reducing the need for a persistent staging branch (which usually then has to get merged into master later on to deploy)
  • The staging branch+website is always the latest code, greatly simplifying QAs’ jobs by not having n number of different netlify deploys to go look at, and devs’ jobs by integrating sooner with other dev’s code
  • Deploys to prod website can be manual (by unlocking the deploy and then locking again)

Thoughts?

[edit] from a very naive perspective, it seems that netlify maybe already has the core functionality to enable this, it would just be rearranging it in a different way. But software is hardly ever that easy :smiley:

But this would be a huge boon to devs/companies that do trunk-based development, which currently with netlify is a pain and a blocker in many ways. We’ve considered moving off of netlify because of the difficulty of trying to get a good trunk-based development workflow going.

Hiya @anthony1,

We try not to judge folks’ workflows; I trust you have a reason for wanting what you want :slight_smile:

You can link as many sites as you like to the same repo, put different names and different configs on them, even if you build the same branch.

I think that will solve your problem without much hassle, but let me know if not!

@fool

We try not to judge folks’ workflows; I trust you have a reason for wanting what you want :slight_smile:

Trunk-based development isn’t some strange idea, it’s quite popular and common. :slight_smile:

https://www.optimizely.com/optimization-glossary/trunk-based-development/

https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development

It’s a workflow that Netlify just doesn’t really support that well, and I’m hoping that my suggested changes make the support a lot better.

I think what trunk-based devs are doing currently is just building elsewhere and then using the Netlify CLI to upload to various sites. Again, not ideal, and it could be so much better if Netlify supported this workflow directly.

You can link as many sites as you like to the same repo, put different names and different configs on them, even if you build the same branch.

Thanks, I’ll try this for the moment. It’s just not ideal to have two different places that I have to manage website config/settings.

An issue I’m running into implementing this workaroud, though, is that the deploy context for both sites is production but that’s not what I want it to be for my staging website. (E.g. we’re using a netlify.toml file with different contexts to determine which API backend to hit. But if both the “staging” website and the “production” website have the production context, they’re both hitting production APIs.)

Is there a way to change the context, or is it always just determined by the main branch? I wasn’t able to find anything concrete in the docs. But I could have missed something?

If not, then I think my next best bet is to just pull deploys out of Netlify and do them somewhere else (e.g. CircleCI) and then upload the built files to separate Netlify websites? (alternatively, I can change those to run-time variables as well)