 Welcome. Glad to be here. It's quite exciting. We have a lot of representatives with a lot of very nice things to talk about, certainly. This is the battle. Of course, it's not a battle. They don't think. Yeah. And the crowd leaves. But we're definitely going to have a very good discussion about the local development tools for Drupal. My name is Hikaru Mano and I'm from Acquia. And then we have Randy Faye. We have Marc Casias. Alejandro unfortunately is sick today, but he asks to apologize himself. Then we have Angin. And then we have Matias and Michael Schmidt. So for the people that just came here now, we have an hashtag on Twitter. So you can actually make questions. By the middle of this session, we will have Q&A. So your questions, I'll pick some questions from there. Of course, eventually not all questions will be able to be answered, but we will have the time to go for them. So yeah, that's the Twitter slide. Don't forget that. And then let's start with Randy. Randy. You have two minutes to pitch. Yeah, two minutes. Actually, I want an extra two minutes. We only have two minutes and 30 seconds. My name is Randy Bay. I'm the maintainer of BDev, which is one of these tools. But I want to first make the pitch for why you want a local Dev tool. So all of these tools will work for you. How many of you use one of these tools already? So maybe a two-thirds, three-quarters. And there's another set of you that are running MAP on your Mac or WAMP, or you're installing Apache and you're running FTM on your machine and that kind of thing. And that is a valid approach. And I did it for years. And I love it. I'm one of those dev ops guys. I love tweaking it and putting the right thing. But the reality of managing your own environment instead of using one of these tools is that you're going to spend your life either fixing your environment or fixing that junior dev over there fixing a burn environment or his environment. You're going to have that problem for the rest of your life and your team is going to spend more time working on your environment than they're going to spend working on what you're supposed to be working on. And I think all of these tools are aiming to get you set up in a place where you can predictably have people working on the development they're supposed to be working on and not working on their environment. Does that make sense? I think it's really important that we start there. And it's really important to recognize that all of these tools are aiming to solve that one problem. And they all do it, you know, everybody's got their own strengths and that kind of thing. But it's super important. And I think all of the tools are Docker-based. Is that true? Everybody's Docker-based. So if you're not familiar with Docker, it's a way of basically running little Linux machines on your computer. And each of these tools wraps Docker in a slightly different way so that you can have a predictable environment. As you probably know, almost all server environments are Linux and almost all of them are running Apache or Nginx and PHP, FPM. So in the world of these tools, you're running in a predictable container that is like your deployment environment, which is another big win. It's much closer to your deployment environment. It's a good thing. There's nothing wrong with running your own. It's just got, you know, the problems that I talked about. So let me talk about DDEV just a little bit. How many are you using DDEV or Trident? Thank you very much. Thanks for doing that. DDEV is a Docker-composed wrapper that is wrapped in Go language. And it works the same on Windows or Mac or Linux. It works exactly the same. The amazing thing about Go as a language is that you can compile into a fat binary that just has everything in it. It's astonishing. And so we just build all three binaries for Linux and Mac and Windows all at the same time. And we have none of those problems that you typically have of what to support it with. They just run on each container. So DDEV local is, I think it's really easy to learn, easy to get that first startup ramp. It is a command line tool. And we don't have a supported GUI for it. We wish we did. But you know, you can only do so many things. But DDEV local is a command line tool. But you haven't tried it. I hope you'll try it. You can install it with Homebrew if you're on the Mac or on Linux. There's a nice Windows installer. You can install it either with Chocolati or just download the Windows installer from the GitHub releases page. And it's a command line. You can go into a directory. Just make a jump. DDEV config and DDEV start. And put an index.php in there, an index.html. And start it. It'll give you a link. You click it. And there you are. You're on it. So it's a pretty straightforward startup environment. Most people don't have much trouble. We have excellent communities for one amazing community and the Drupal Slack and the DDEV channel get lots of help there. Lots of people, the whole community, and we're there. Support is a very high priority for us. We really want it to work from you. And we learn from you. And we want to help. But we also learn from everything that you run into. There's always things, right? A normal project startup, if you've already pulled the containers, is about 20 seconds on most environments. You can run all kinds of different things. We have explicit support for typo 3 and every variant of Drupal and backdrop and everything else. Got a different config for each. We don't have as many, you know, like Doxel and Lando have great documentation about how to do the most amazingly complex services. Really excellent. Lots of good stuff. I'm not familiar with everything else, but some great documentation. But we have documentation for a number of services and almost every problem that everybody's tried to solve they've been able to figure out how to solve it. And so we have, you know, extensibility documented, extensibility for solar and memcache and just, you know, dozens of other things. Lots of problems solved there. We've been working on a regular maintenance schedule. We've been having a release every month or two. When you need a feature, we've been trying to get it to you. You know, can't always, but we have been doing that regularly. And we wish we had a GUI. We probably will someday. But right now it's a command line. So that's a disadvantage. Alright. Cool. Thanks. Next is Mark Casillas. Casillas. Casillas. I'm not going to stand because I'm lazy. I actually am a software engineer for MediaCurrent. I am not a part of the Lando team. They, I was talking to one of their sportsmen, Mike, who's one of the main developers about something. And he said, man, you're going to Amsterdam. Here's a t-shirt. Talk to people about Lando. Here I am. So the thing about Lando, the thing about to Randy's point is that it's, as somebody who works in an agency, you constantly have different configurations of where you're going to deliver your product. And the whole phrase, it works on my machine, but it does not work well in an agency life. So the thing about these, whether it's a vagrant or a Docker solution, is then you have an environment that emulates wherever you're going to deliver it to. And that's what makes these really good. Lando, the reason I got involved with Lando, I've been using it out of the box. Again, to Randy's point, no one wants to, or I am not one of those people that will want to configure my machine and reconfigure my machine. I want something that's a simple YAML file that I can just fill out and go. And that's exactly what Lando gave to me. Real simple out of the box, it fires up a bunch of Docker containers and I can actually run a Drupal in a LAMP environment immediately. I can run it in a, what's the one with, that Pantheon uses? Yeah, yeah. Just have that all running really quickly out of the box and I don't even have to mess with it. And again, it's a YAML configuration. They have a really great, there is not a GUI but there is a great command line interface where I ask you what type of service you want to use. Do you want it to be PHP 7? Do you want it to be PHP 5.6 still? Don't, you don't want that. But you can't, you have those options. It's very, very easily configurable and then once that goes through, you can simply make the adjustments, say your solar is out of date and you want to update it on there. You just have to make the update on a YAML file instead of having to mess around with things. It makes your life so much easier. Another thing that I really like, I do enjoy using the Pantheon service and Lando has a way that you can actually pull an entire site from Pantheon with a single line command. All you need is the ID of the site and you have your full Pantheon site straight up, no questions asked. You pull down the database, do all the work, you have the exact same thing. It makes life easier on there. Anything else? It actually works well with Drupal and WordPress and Node, although I really use Node locally. I don't really use Docker for that because it all compiles with MBM. You can have that there. Yeah, so it's great. I enjoy it and hope you try it. But again, to Randy's point, using one of these tools, we're not going to fight because you're going to use something that's going to make your life easier, not our life easier. So have fun with that. Okay, thanks Mark. Next is... Engin? Yeah. Doxel. Hello everyone. I'm Engin and I'm working with the developer at FFW. I'm here as a Doxel fan. We represent Doxel because none of them maintainers are here today. So I will first start explaining what Doxel is. It's, yeah, similar to the other tools but still. And then provide its benefits and its features in order to convince you. So Doxel is a tool which helps you to quick start a Docker powered environment for development. And its guarantees basically consistent results for a project member. So it comes with a command line utility called FIN and some configuration for Docker compose and the corresponding Docker image library like for PHP for several versions and Apache MySQL but also solar elastic search, one-ish and so on. And it provides your way to set up a project with your configuration but at the same time you can also it has also flexible configuration for advanced use cases. It has boilerplates for different projects or applications like Drupal WordPress Gatsby WordPress and you can basically choose results with FIN project rate what to set up there. It is a from my point of view documented CI integration which works well now on CI pipelines like Bitbucket Circle CI or GitLab GitFCI which you can use in order to have branch or environment per branch or also persistent environments like a development environment or a UAT environment where you can do QA for example or UAT for your clients or demos for your clients. It has also Web IDE built-in currently it's cloud 9 but with the next release it will be I think Visual Studio Server with Xdebug integrated so basically doxels they're removed the image of onboarding developers onto a project they will be able to set up their local environment within minutes instead of hours or days like every other project here and no matter what launch stack you are using is it windows, layouts, Mac or CI it is there to have contested results basically it is open source and free it is developed by and supported also by large Drupal shops and big live-in community Next is Matthias Launchpad Hello I'm Matthias I'm from a Berlin company Dropsolids and I'm here to represent Launchpad Launchpad is actually a tool we start as a pad project and we start to use it to also improve the onboarding time of people because it's really hard actually to say that friends have to make some local development stack working for everybody so it start as a pad project to make my own local environment working then move to support and we are actually using it to do our daily development it's actually based to fast and maintain we don't need much maintenance to make it work so like all the tools you fill in and you can get started it also has a big advantage that it's completely integrated to our platform and that's actually the biggest benefit you just type the command to get a project and in a couple of minutes you have completely clones database everything there so currently it's only actually all solving the same problem as getting projects running fast and on the local machines so at the onboarding time dropped really really it's a huge improvement like the hours or days are just so together with the media or senior developer get locally running and you start on the projects without hassle and without to have to know the technical details of the project so it's developer focused so it has all the necessary to debugging or profiling or like everything that's needed there to really get into that to fix the problem is there native support for Xevox on the CFI2 because it's sometimes hard for people to set up so yeah it has all the tools there to really get into that to fix the problem and it's extendable per project so yeah it's configurable basically it looks a lot like DDEV but we have a different approach on some stuff but yeah it's kind of similar in approach so yeah everybody in the audience yeah I guess I'm here my name is Michael I'm here to represent Pikmi so Pikmi actually has an interesting story it was literally built on a weekend by me because so we are a hosting company and we do Docker development container hosting and we realize by fast that the local environment or the local development system is not as great as we were hoping it is so a bit desperate we just built something with some other tools so Pikmi is really that's like 300 lines of code but it basically uses a lot of other open source as possible so we have an HAProxy we have a mail hog we have an SSH agent in there but you just run it once and then you run and your post has then some environmental labels that is wrapped by Pikmi and yeah but we're actually as I was just built on a weekend and my plan was to maybe maintain it for two months now it's three years and so we're continuing to maintain it but we actually decided as Lagoon that we're going to support other tools so we're starting to work supporting with Lando first and because we really see that running our own tools especially for a lot of agencies. I mean, the amount of fighting about port AD that I see on local computers, port computers. And so, yeah, we said, okay, we will continue to have Pygmy. We're actually rebuilding it to go right now, because Ruby is not cool. And especially like we've heard before, running it on different environments, it's a bit hard. But the end goal is to actually say, like, we want to support all the main tools. So I'm here to solve problems, but also to a bit understand, like, okay, where is the world going? Because I think last time we checked there were 35 different local development tools. And so it's good to see now a bit less. But I don't know why it's so good. I'll try another one, make it 36. The ultimate tool that will solve all the problems. All the problems. So, yeah, that's me. So let's go to the questions. We got series of questions. The first one, and I think it's directed to everyone here. So I want to start answering, go right ahead. So how do you tackle the performance issue of Docker on OSX? The Docker on Mac has a problem with basically all of these tools take the strategy of mounting your project, your code, into the container. And then you get your web server running inside that mounted container. And on OSX, and to a certain extent on Windows as well, it's not as fast as we wish it was. So DDA takes the approach of turning on caching first so that Docker has explicit caching. And that actually works for a lot of people. A lot of people don't complain at that point. But there are two other techniques. One which we tried and failed at, and one which works pretty well. And most people can beat up with really big projects, like big Drupal 8 or Magento or type of three projects. We are recommending that they use NFS. So you set up NFS on your Mac, and then Docker can mount the NFS into the container. And I would say it's five to ten times faster. That might be an overstatement, I'm not sure. But Magento, for example, without it, it's just way too big. And with it, people are happy to work with Magento. So there's one other strategy that you've probably all heard of is the cache syncing technique where there's a few different tools, classic tools, that will take two repositories and try to sync them, two-way sync. And they work. And we had one. We had one. It's actually still in there. But it just broke. And two-way caching is a really hard problem. So we were unable to support that successfully. Anybody else want to talk to that? It's a really sad story. I feel like it's unfortunate that Docker does not decide to open source Docker for Mac, which would allow all of us to actually solve the problems. And instead, they're just keeping their issues and saying they're working on it, they're working on it. I don't know how many people are actually working at Docker, four Docker for Mac, maybe zero or one. So I think that's a really, really sad thing. So one of the things that we are starting to do, and it's maybe a bit more the advanced version, is to actually not mount the whole Drupal repository into it, but to explicitly mount only the custom module. So you mount module slash custom, theme slash custom, and all the core and all the mentor and all of that lives inside the Git repository in the container. So it's only built inside the container, because the slowness only comes from when you mount volumes. If you have volumes that are in the container natively inside the VM, yes, Docker for Mac runs a VM, you don't see it, but it's a VM at the end. Then it's fast. So the problem is you end up, then if you want to run XDebug, then run that needs access to all your files, it gets a bit more complicated as soon as you want to go into debugging. But at least that has been for us a bit of solution for a couple of things. But yeah, it would be really great if somebody solved the problem. There's a strategy like what Michael said, that people use on Typebook 3. They have a bar directory, which is like Drupal's temp, which has no business being mounted in there. It's throw it. And so the solution to that, which works great, is to mount on top of that attempt volume. In there, it's always in the, like bar is at the root of stuff. And so that's a good technique. Anybody else want to speak to that? I was just going to say it's a great reason for me to go get a cup of coffee. I'll get the punchline, or use Linux. Can I just make something? You have to tweet your question and then we can get it. What? Is this another option for the question? Yeah, you can have it on the end if you want or then just tweet it. Okay. So we have a tweeted question. The next question is, sorry, we have to have some kind of order here. So the next question is actually a very positive and interesting one. And it comes from the audience here. And it's saying, we are all doing the same thing in parallel. Why not collaborate more to actually build the best tools? Who wants to go first? Yeah? Sure. I mean, that's one of those things where you have 26 competing standards in life. So let's write a 27th one. And now there are 27 competing standards in life. You do everybody's trying to do the same thing, but we're all taking different approaches. I think that the point is we're all trying to get to the same place. And eventually, you know, there's going to be one ring that rules them all, but we're not sure if we're there yet. We're hoping to. But eventually, we're all trying to do things like some people are trying to have their tool for their specific platform. Same with Lagoon. You know, people are trying to run it for their specific things. Others are just trying to get kick the can further down and make things happen. So it's kind of hard for us all to, like, bring our heads together for one thing because we all have certain different drives. I think would be a good way to say that. Anybody else? Yeah, I think that's true. And when I started working on lunch, my biggest struggle about whether I invent something new or just start using something that already exists. But that's that point. That's like a year and a half, two years ago. The speed issue wasn't fixed in any tool. Like, I started building something myself and then it worked. And then, yeah, I think it's good to have, like, multiple tools because every business model or every organization has its own way of solving things. And the physicality you have to add and to make your tool working for your organization is seen as overhead at that point. So yeah, I think it's good to have, and all together we can weigh in like on Docker, I guess, because, yeah, or not. I don't know if Docker ever listens, actually. I have the same issue. You can be an issue queues there for years and not have anybody from Docker respond. But I think it's a good way to have multiple tools to look at it, to just be able to weigh in more and to find out the best solution for everything. Yeah, I mean, that's exactly the reason that we're trying to get rid of pity. It's exactly the... I fully agree that it's super confusing why there are so many tools. I think we just have to understand that there was nothing at all out there before. The only one was MAM, basically. And then, of course, a lot of people at the same time come up with trying to solve different solutions. And I think it just will take time. Like, right now, we maybe are in the situation that there are a lot of tools. But if we may be talking to three years, there's maybe only four or five. And I think it's just a natural how things are happening. But yes, if you are sitting here and thinking about, ooh, I should create another tool, please don't do that. Come aboard to one of us. Yes, they're all open source. If you don't like something in there, just go and fix what you don't like, but don't create the wrong tool. You're not going to make a lot of people happy if you don't do that. So I do invite all of you to, I would love to collaborate. So we can change our direction to meet the needs of what other groups are doing. DDEV is really open to new paths and to explicit support. And we've added a lot of things in. We have explicit typo 3 support. And typo 3 is another CMS very popular in Europe. You might not be familiar with. Type of 3, very popular around here. Type of 3 found DDEV and they just went with it. It's in their docs. Nobody uses anything else. They just use DDEV. And Drupal, the Drupal world is very different. Drupal is always building this module and that module and all these other things to solve all these problems. You can never imagine a decision like that being made in the Drupal world. But still, because type of 3 wanted that support, we were able to do what they wanted to do. And we can work together to meet the needs that all of these different tools are trying to meet. So there's possibilities there. Okay. We're running late, but there are some other questions here that can be actually talked about. We have time. Now we have two really important questions. They were tweeted long before the session. And one of these questions is this one. What are the most common difficulties found by users when using your tool? And I would like to go to which of you if possible. So what users find difficult using your tool to your knowledge? A lot of it has to go around. And again I am a user more than I am a developer of the tool, so from this perspective, working with people at media current that use Lando, they have a bit problem with the performance issue of Docker the way they get into the NSF mounts and whatnot causes it to move a little bit slow for their liking. I honestly haven't seen that problem. The training, we did a training at the beginning of Drupalcon for component development and we set everything up on Lando for it to work. And 90% of the people worked great out of the box. The couple of problems we have were people with windows that had some weird windows of Docker issues that I honestly couldn't solve which was really frustrating. So there is a bit of a problem with Docker and Lando in windows. It's getting better with hopefully that's actually one of the bugs that is preventing the full release of 3.0 of Lando, which we'll get into in a minute. And so those are probably, I would think, a performance problem. Also if you have any custom configurations for ports and stuff like that, Lando does not expect that. So it kind of freaks out on you and it doesn't seem to work for some people. So with DDEV, I think people who are used to working on a command line they just get in there and it works. But people who aren't used to the command line, they just, you know, DDEV's command line driven thing and they look at it and they say, what's that big black thing? Why is it blinking at me? That's why someday we'll have a GUI that simplifies that for people that are used to that. But I think that's probably the biggest thing. Well, same for Docker. I mean, those people might get scared off if they need to start using CLI. So that's one of the issues that there is a graphical interface. And the other one is if you need to have a launched use cases then you need to have a knowledge of Docker or Docker compose and that's also something difficult, I would say, because we provide a way to easily start a local environment and get a stack running and then they want to do something more and then they need to get now Docker and Docker compose the biggest issues we encounter was when like a new release of Docker for Mac or something changed internally, you have no knowledge of and suddenly it breaks or it has a performance penalty you didn't expect beforehand. And also that if somebody wants to override something, you need to have some inner knowledge of a Docker compose and that's actually why the tool is there, to not have to have that knowledge. Some people are fine with just using a tool not knowing the internal, some people want to know the internal so for the people who want to know it's no problem, they can figure it out themselves but for the others it's sometimes harder than just get that part there, that works there. For the syncing issue like Randy said, there was previously no proper sync and at that point your sync just could get stuck without any notification so you just was there and why is my change not going into my content rather than why is my change not visible and that was very hard to explain to people why it broke down Yeah, for us it's actually interesting, it's a window support we do a lot of government right now and yeah, they are stuck in Windows They are working with Windows but no, the problem they are stuck with is that they can actually not install all the tools they need. So Docker again they only support Windows 10 Pro or Enterprise so many companies don't like in many times they don't have that version or they don't have the permission to install it and so that's actually really the hard part right now and so then they end up in like running, I don't know, like a map again or like other weird ways and so that's a bit the challenging part I don't think that anybody can actually solve that because again it's a Docker problem and so one of the things we are looking at is just to go cloud IDE all the way so to maybe offer a way that you don't need to run anything locally like basically what you need is a browser where you can just go in and you can say which environment you want to edit and it opens up an IDE and when you edit it, it updates it on the server all the time I was a big opponent against that for a long time because I want to have stuff running locally but I see so many issues that this is like we are trying to convince people to give us a admin access and that's such a big issue and it's not going to be the preferred way like I still want to support it locally but yeah we just realized at one point you need to find another way than local okay thanks very much so I would like to finish because we are almost out of time just giving you some room to actually talk about major plans and the roadmap for your own tool how is that going to stop yeah for us the major plan is to support other tools it's probably going to be in go and because of profitability but if you want to use it really like if you also use other hosting platforms and stuff like that we want to have possibilities to run Lagoon images on other tools and I think that's our contribution that we can make to not create the 27th tool so that's going to be our roadmap I don't know how long it's going to take and if somebody is off the land or docks or whatever tools wants to work and help and we can provide our services and our time and to do it but I think that's the way forward is to not create another tool to actually open source it's not yet open source but I think it's very useful for everybody to just see how we solve some issues and to just learn from each other and then eventually have a good discussion about the long term path forward because I don't think all the tools will be gone into one tool in like next two years or something it won't be possible and that's not possible for a specific it's the documentation it lacks documentation there are known bugs and features that are not documented and some of the issues also people struggle with is to know how to use specific things and for the rest it's more not trying to reinvent the wheel I guess and to really get support for other platforms or the other way around to get more involved into other tools For Popsaw as I mentioned earlier there is a built-in web IDE which will be released and the next release is Visual Studio which is also terminal integrated and it's debug then it is planned to combine the sandboxing feature and this web IDE in order to have an integrated on-demand cloud based development environment and which can be used for sprints or trainings or data development needs so you don't need to set up a development environment and it is planned to refine some of the core docs to production hosting ready and also to have deployments to Kubernetes cluster of sandboxing environments DDEV's roadmap is public out there you can just Google DDEV roadmap and you'll find it but the some of the biggest things that we have on the list are support explicit support DDEV already works with almost any PHP or JavaScript or HTML environment but we want explicit support for Magento we want explicit support for a number of other CMS's and we're getting toward that and our WordPress support has been lagging but WordPress people are starting to use it more and so we have to catch up on that so that's probably the biggest things that we have on the roadmap anyway it's all there waiting for you to look at. For Lando, same thing you can actually search for the Lando roadmap as well they're trying to get a stable release of version 3.0 out the door by January 1st they also want to work with more integrations of I talked about the integration with Pantheon earlier they want to do more of that with other ones as well trying to get that in there but one thing I had to warn you at the bottom of this link they talked about a marketing mascot and they click don't click that link it's not what you think it is so that's it. Somebody had a twitter question about WSL 2 and I just wanted to say it is awesome so if you work on Windows WSL is a Linux environment built into Windows and the new version that's coming next year currently it's only an insider built but it's called WSL 2 it makes Windows be a great Linux machine and the Docker technical preview is headed that direction so the Docker edge on Windows has a specific WSL 2 version built into it and we want to support that exclusively because it is a beautiful thing well it's beautiful when it stabilizes but it's beautiful when it's working right now it's just great. Okay actually I was going to put that exact question but that's fine okay so the question was coming from the audience and I think we still have time for one more question or two is WSL solution for performance issues on Windows in your case maybe interesting to respond. Yeah I mean it's definitely very interesting to see how Microsoft pushes the whole Linux on the desktop I mean that's really cool and the problem again on my side is that my users cannot actually use it or install it because of the permission they can't get Docker installed. Yes they cannot install anything like they double click and install it. Not even that no it's like it's not enabled as a feature in there that admins can install for a lot of Windows for government sites and you don't have that option. So it's great like I'm not saying we're not going to use it and I think yes that the direction that Windows goes to support Bash and all the other Linux stuff is really cool and is also crazy that we do that but yeah it's still you need to have permission to actually use it. You know in WSL and WSL 2 you can do stuff sorry you can do stuff in the container that you might not be able to do on Windows you might be able to install Docker in the Windows container that's not the same as the Docker that's the tech review but it might solve your problem. Actually you still need the WSL role to be enabled as a feature. Oh you still have that but I agree it will be a good entry point because if you just get that check box checked after that you can run or whatever you want to run because then yes so I think yeah it's going to be an exciting time what's going to happen with Windows and the support of WSL I mean there's more and more dots coming and yeah suddenly maybe we'll all switch to Windows and develop there. Okay we still have three minutes I think one last question and then the last question is which of the DevTools is supporting local SSL certificate? Loged by this. There is a traffic container in front of it so traffic is in reverse proxy now it's more than that but it's used to SSL of loading and reverse proxying to around all the traffic and we do SSL of loading there so you can test everything with SSL no problem at all. With a trusted server? Yeah with a trusted server it's generated when installing so it generates a local only locally so it's no security issue it's only on a local machine that you trust a specific server only used for a launchpad itself and I guess yeah that's actually the same for everybody using these sort of things. Data that uses makeser and by default you have trusted SSL which is really nice yeah same with Lando and you can actually create a custom TLD for yourself if you want to use it don't want to use the dot Lando dot site that's on there all the time. You can create your own TLD and then generate a server for yourself and then it's a trusted server as well. Okay everyone this was great we have to have very important I believe. Okay but people on Twitter didn't get their question answer so I think you can get there to happily stay around and answer any questions. But the session is terminated now? Because it's terminated? Yes. But you are able to stay and make more questions to them. Thanks everybody. Thanks.