Talking Drupal #521 - Tugboat

Nic: This is talking Drupal. We could chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 521 Tugboat. On today's show, we are talking about tugboat, what it does, and how it can supercharge your CICD process with our guest, James Sandsbury.

We'll also cover Shirley as our module of the week. Welcome to Talking Drupal. Our guest today is James. He is a musician turned web architect. With nearly two decades of experience building large scale digital platforms, he has led projects for major brands including Intel, Cisco, the Recording Academy, Martha Stewart, Sci-Fi, Bravo, and M-S-N-B-C.

He's now CEO at tugboat and helps teams ship high quality code quickly and confidently. James, welcome back to the show and thank you for joining us for the last few weeks and for celebrating your 20th Drupal with us.

James: Nice. Yeah, I didn't even know it was my 20th, so, but yeah. Excited to be here with y'all.

Nic: I'm Nic Laflin, founder at nLightened Development and today my Cohost is John Picozzi, solution architect at eam.

John: Hello everyone.

Nic: And now to talk about our module week, let's turn it over to Martin Anderson Klutz, a principal solutions engineer at Aqua, and a maintainer of a number of Drupal modules and recipes of his own.

Martin, what do you have for us this week?

Martin: Thanks Nick. Have you ever wanted to use Drupal as a URL shortening service? There's a module for that. It's called Surely. That's spelled S-H-U-R-L-Y. Surely you're not serious. The module project is actually dedicated to Leslie Nielsen specifically for that reason.

Classic line from airplane. The module was created in August of 2010 by Jeff Robbins, though recent releases are by Jiao Ventura of Portugal. It has an eight point x dash 1.0 dash beta four release available, which supports a Drupal 9.3 10 and 11, and it is marked as mini, minimally maintained maintenance fixes only.

And the project page says that the eight point x branch is not ready for production use. So a big caveat mTOR if you decide to try it on your own. Now for security coverage, it has opted in but doesn't have a stable release currently. It has 18 open issues, five of which are bugs against the current branch, which isn't bad considering it's officially in use by 730 sites according to drupal.org.

Now with the surely module installed, you can specify a long URL you want shortened optionally, also providing a case sensitive short URL you want to use. If none is provided, a short URL will be automatically generated. The module provides usage data for the short URLs, and as a user, you can see a list of the ones you've created as well as their click data.

This is a little surprise to see that the created short URLs are stored in a custom DB table instead of its entities. But the module is able to avoid a full bootstrap of Drupal before issuing the intended redirects module provides blocks for creating short URLs, a bookmarklet to save a short URL and URL history.

There is also views integration for listing the short URLs by user or in whatever way will be useful in your site. There is also a submodule to provide web services for generating short URLs or potentially expand a short URL back into its long form. The services support output as text, JSON Js, O-N-P-X-M-L, or PHP serialized arrays module allows.

You to provide a variety of permissions to give fine-grained permissioned access to capabilities it provides, and also has features like pearl rate limiting APIs to alter redirection, logic and support for the Google Safe browsing API and Google Analytics. It's worth mentioning that the Shirley module is intended to run in a site on its own instead of within a Drupal site that is serving content directly, but it will attempt to avoid collisions with existing site paths.

Now, today's guest, James, is one of the maintainers of Shirley, but Nick, you mentioned before the show that you have a customer using this module. So why don't you start the discussion by telling us, telling us about your customer's use case and your own experience in working with Shirley.

Nic: Yeah, so we've been, so my client's been using Shirley for.

I think 10 years now. They use it extensively. And they use it in combination also with like a redirect kind of a similar site that just does redirects. Right. The main purpose for surely for them, by the way, isn't just the shortening piece. It's also they use it in a way that they can provide a lot of the marketing collateral and like tokens automatically.

So I, they're gonna hear this and I, I may get this piece wrong, so if, so I'll correct it next week. But you can, you'll set up the short uur l that you want. Like, hey, fancy new marketing term. It adds the, you add all the parameters that you want on that particular URL, and then it kind of redirects you to the actual URL and Appends those.

Query parameters on it so that when they're marketing something, they just throw the nice simple URL and all the collateral that they're using and anybody that clicks on it gets those UTM codes and everything added automatically. They don't have to like make sure that they're including them in every single website or whatever.

And if they are change, if they, if something is wrong or they need to tweak it or add something, they can always just edit the entry and update the attribution to whatever they want the attribution to be moving forward. And any old link will now get that new attribution as well. So yeah, they've been using it forever.

It's one of the last sites that we have on Drupal seven actually. And we have a project open that's not the highest priority, but we've been slowly working on figuring out how to get it to Drupal 10 or 11 or

whatever. But yeah, it's served us for a very long time. Powerful. Nice.

John: So I looked at this when you suggested it and I was like, this is a great idea.

And then I went down the rabbit hole of like trying to figure out what the best shortened URL would be like. 'cause I think like, looking at this for like my own, my own blog, right? Like it would be interesting to have a shortened URL that I could use for like, blog posts and like, you know, other, other, other stuff like that.

Mm-hmm. Kind of to do, to do that tracking, because I was, I was interested, if you look at the module page, it talks a lot about how it kind of tracks all the clicks and everything, which I, I was like, oh, that's interesting. Mm-hmm. I'm like I just can't figure out, I just can't figure out a good a good, you know, short URL.

That makes sense. So, like the domain you mean, or Yeah, yeah, yeah. Like the domain. Mm-hmm. Which, I mean, I guess I could just use it with my own domain, but mm-hmm. You know, it's always

Nic: that defeats the purpose of it. Like the, the whole point is, it's like Bitly

John: yes and right, yes and no. Right? Because like my blog post, like a blog post link on my site at least always is like, domain slash date slash title.

So it's like really long, right? Mm-hmm. So at least if it were shortened, it could just be like domain slash some short. Thing to, to get somebody there, right? Yeah. And then I'd be able to keep track the, keep track of those clicks a little bit better. But,

Nic: but that's, that's still just a standard redirect, right?

You, you could just kind of redirect.

John: Yeah, no, it is, I, yeah, absolutely. You, you are, I guess if you were,

James: if you were trying to get metrics on different campaigns or something like, or different social networks or something where you could say like, yeah, okay, I've got this short, short, short URL that I use on LinkedIn and this one on.

John: Yeah, that's kind of, that's kind of what I was looking at is like, how can I track where they're, where they're coming from and I know somebody mm-hmm. Listening that is like, Hey, dummy, like Google will do that for you. All you have to do is X, Y, and Z. Yeah, yeah, yeah. But like, I don't know. I was just thinking, but then you've gotta have,

James: you know, Google Analytics running on your site and some people don't wanna do that.

So I think it's a valid, it's a true story, true story.

Nic: Absolutely. It, it's, it's a cool project. I'll, I guess I can keep you guys updated too, as we make the move to triple 11 for that are,

James: yeah. Are you gonna be helping with the, the upgrade for the module? Or,

Nic: I don't know. I, I have a feeling that the, if you look at the module page, it says the Drupal eight version is still in development, should not be used in production.

Mm-hmm. I have a feeling that that is a very outdated statement and considering the only supportive version is the Drupal eight and it, it was updated in September. I'm sure it's being used. Yeah. Yeah. It also makes me

John: wonder what used in production means, like mm-hmm. Because I, I, I think if you look at the, the module page, there's a link to a like a, a lulla bot.

Page where they used to kind of offer it for as a, as a free link shortener. Right. So I, I'm wondering if that's what they mean by used in production. Like you could use it for your own internal purposes, but maybe not so much as a like, Hey everybody, I'm gonna give this to you for link shortener production

Nic: just means an external facing things like what my client is doing is production.

I, you know, the funny thing is that there's, I think there's two pieces that we're, we have to be very careful of to make sure of for the move. One is we've like you said, all the, everything is stored in custom database tables, and so we need to make sure that everything migrates properly there.

Mm-hmm. We have some fairly extensive customizations to the creation form, to like I said, to allow us to add all the different attribution things that we need and. There's also some fairly I mean, it's not that extensive and I'm sure we could do it to modern Drupal pretty easily. I just haven't spent, it's one of the requirements and I haven't spent any time whatsoever thinking about it, but we have things to block people from trying to visit the website directly.

So basically you're only allowed to get, you are only allowed to use it to get the redirect. You're not allowed to visit the site directly unless you're logged in or authenticated from somewhere, because we don't want people, I mean, it's, it is a Drupal seven site, so we don't want people getting to it.

But like you said, because it does it early bootstrap, it's not a, you know, the surface, the attack surface isn't very high because it's, you're just immediately getting redirected before Drupal is even doing anything. And then

James: we, yeah, and if you've got caching in front of that, then the, the re x would be cached as well, so Yeah, yeah,

Nic: yeah.

It's ho it's hosted on platform right now, so, you know, nGenx and mm-hmm. Cloud in front of that, so Yeah. Yeah, yeah. We get multiple layers of caching, so

James: Yeah. Yeah. I was a part of the as as Martin mentioned, some of the original development of this back in the day and when it first, when Jeff Robbins first created it, I think it was actually because like the do CM domains had come out or something and he purchased lb cm and then was like, I want to create a URL shortener with this, you know?

And so we ran for a while. We ran a public, like you could create an account on lb cm and, and you know, start shortening URLs back then. There's still lc

Nic: cx, which is lc cx. Huh. Which is, I don't know what that is. It's like a French.

James: Okay. Yeah, so that must've been later, but I guess I say this all to like dissuade anyone from trying to run your own public short URL shortener service because it very quickly turned into just a link.

You know, ClickJacking sort of scam schemes. Yeah. All sorts of junk in there. And we were constantly having, you know, getting things flagged. And that was, I think maybe the development work I did was integrating with the what was it called? The Google Safe browsing. Yeah. Whatever. So that we could actually check the URLs before we would create the records or whatnot.

But there was all this stuff we tried to do, and then eventually we, what we did is converted all of our short URLs that were valid into an HT access file and just took the whole service down. And so now, now we maintained an HT access file. So,

Nic: well, if you, if you think about it, so the way my client's using it is perfectly valid, right.

We we we're the ones adding all of the Yeah, yeah. That's a valid for sure. Short, right? So we, so we, we validate them, but mm-hmm. You know, even though it's kind of, it's something kind of created on the whim, Jeff's whim. You know, it sounded like, oh, this is a cool idea. It, it's still valuable because Yeah, especially for a company like Lobo, learning how to manage something like that is valuable for a lot of your, I, it's for sure.

John: It's definitely valuable as an internal tool. Like, I don't know that I would ever like, be like, Hey everybody, use my link shortener. But like,

Multiple: yeah.

John: To catch, to catch me, me to catch metrics and like, so I even was thinking just now as Martin was talking about it, like, oh, well, you know, talking Drupal posts a lot of links to a lot of different places.

Like it would be mm-hmm. It would be useful for us to maybe have a link shortener even for like our like our resources and our show notes mm-hmm. To know which, you know, which links are people are clicking on and, and you know, kind of have metrics to that sort of thing.

Multiple: Yeah,

John: so like. I mean, I definitely see a lot of, a lot of good uses, uses for it.

I just I don't know. I, I think it was ambitious to like open up a public and, and think, like, think like the internet wasn't gonna turn it into, you know. Yeah. Well,

Nic: well, that, that, that, that's exactly what I meant though. Like for for a company like Lobo, when you are handling, your companies are, or your clients rather, are companies like M-S-N-B-C, right?

Mm-hmm. Who has a, you know, they're a news organization, they have a public comment section. Mm-hmm. They probably need to handle all sorts of, you know, screening and public abuse, that kind of thing. Right. Experience at running a system, an anonymized system like the, a public link shortener is something that's valuable to those customers because you could say, Hey, we know.

We've been through the process of Yeah. Moderating something like that. Yeah. We know. Don't do it. What kind? Yeah, exactly. The the short answer generally is don't do it. Yeah. But for a lot of these organizations, that type of engagement is critical and, and timely engagement is critical. Like you guys used to do the Grammys, right?

Multiple: Yeah.

Nic: And so, sometimes, at least in the short term, not doing it isn't an option, but finding solutions for how to moderate in a way that's sustainable, even if it's a, it takes a lot of resources, is, is valuable.

Multiple: Mm-hmm.

Nic: Yeah. But yeah, me, I would never, ever wanna Yeah. Anywhere near who like that. Yeah.

Yep. Yeah. Interesting. And like I said, I'll, I'll keep you guys updated as we, as we make the move to.

All right. Thank you, Martin. As always another on topic. It, it's, here's the other thing too about Shirley. That's interesting. One last note. It's almost a distribution, but it's not, it's like a module, but it, it's like you said, it's a module that's meant to be run on its own instance, Dr. With nothing else.

It's not a distribution, it's not a profile, it's a module, but it's meant to be standalone and there's not, it's kind of unique. There's not really anything else I can think of on Drupal Do org. It's meant to be run like that. Hmm. Yeah. True.

Martin: Yeah. I could almost see it being known like a site recipe where you, it could set your sight up in a bunch of very specific ways because you're, I would think by intent using Drupal in a fairly stripped down way.

Nic: Yeah. Yeah. I mean, usually we, are you really just using it for the form IPI, permissions and authentication? Right. Yeah, there's, there's almost nothing else that we're using it for, for like, there's some redirects and stuff, but that's pretty standard. Alright, as always, Martin. Great. Great topic. If listeners wanna suggest a module leak in the future, what's the best way for them to do that?

Martin: We are always happy to have discussions about interesting candidates for module the week in the Talking Drupal channel of Drupal Slack. Or folks can find me as man clue on all of the Drupal and social platforms. Awesome. See you

Nic: next

Martin: week. See you next week.

Nic: Alright. Okay, before we start on the actual show topic, what's it like celebrating your 20th Drupal bursary?

There's, there's not many people we've had on the show that have been doing Drupal or been on Drupal org rather for that long.

James: Yeah. Yeah. And like I said, I didn't even realize so I actually mark my Drupal bursary different than because I had been doing Drupal for a long time before I actually created an account.

I don't know why I delayed so long, creating a d org account, but but I know that, you know, it was around the, like, I kind of gauge it off of how old my son is, my oldest son and he is about to turn 22. So I think it's more like 21 or 22 years or something like that. Wow. But yeah, it was back in Drupal 4.5, I think for

John: reference.

Mm-hmm. Just for reference, Drees has been on drupal.org for 24 and a half months.

Multiple: Wow. Yeah. Yeah.

John: So nice. 24, sorry, 24 years. Yeah, five months, I guess is how I should read that.

James: Yeah. So I definitely like, you know, got the rocking chair and I don't do, like, I don't actually develop in Drupal these days anymore, so, so there's a lot, I don't know anymore these days, so I can't, I can't really like, you know, say that I've been doing Drupal for 20 years or something like that.

But but yeah, back in those days, you know, I just, I occasionally reflect on. A module that you would download would have a SQL file in it that would have the SQL statements to create the tables that it needed. No way. And you would copy paste them into my SQL directly in order to install the module.

No way that, so this was bef and actually to install Drupal itself, you had to do a lot of that. I feel like we've come a long

John: way.

James: Yeah, I think so. Yeah. On

John: that one.

James: Yeah.

John: 'Cause I don't, I mean, I don't even remember having to do that. Yeah. I, I, I remember you having to like, pull down a module and like unzip it and put it in mm-hmm.

A directory and then install it, but yeah. Was it, was

Nic: it during episode 500? I think we were talking to Dre and you mentioned that there were time, there was a time where. He would change Drupal's API and then write a script to just update all of Contrib to use the new API. Yeah. At one point, like, here's just update everybody's modules and be like, Hey, here's the new a p by the way, update your module for you.

Yeah, you're welcome. That's awesome. I hadn't heard that.

John: It was a much simpler time then. Yes. So James, you say that you're not as involved with coding Drupal. Mm-hmm. I would say that you are still very involved with Drupal because I see you Yeah, for sure. Of Drupal events. You're now on the Drupal podcast.

Yeah. You are the CEO of tugboat. So for those folks that are like, what the heck is tugboat? Can you tell everybody what tugboat is?

James: Yeah, absolutely. So tugboat there's a lot of different ways to describe it, but maybe the simplest way is, is like unlimited staging environments. And for folks that are familiar with like typical GIT workflows version control workflows what tugboat will do is spin up a preview of every poll request that gets created.

And that preview like includes all the data and everything that folks might use to test it. And so the, you know, the, that's like the main use case of tugboat is you know, the having these isolated environments that have just one change in them so that you can hand those off to QA folks, stakeholders, designers, you know, whoever, user acceptance, testing, all that stuff, do all that stuff before code gets merged in.

And this all kind of like. Came out of, you know, trying to solve this problem of, and maybe y'all have experienced it, where you have sort of like the, the end of sprint mad rush on the staging environment where it's like, we've gotta deploy this release to stage and we've gotta test everything so that we can release this on Monday, and if anything fails, we gotta roll the whole thing back.

And so trying to solve that like big bottleneck at the end of the, of, end of the sprint.

John: Yeah. So I, it is funny, I was thinking about tugboat this morning in, in preparation for this, this episode, and I was kind of like, mm-hmm. Well, Pantheon has like multi dev, right? Mm-hmm. So that's essentially like being able to take your code base and spin up other environments.

Yeah. Is is tugboat like that?

James: Yeah, it is like that. I haven't used multi dev personally, but my understanding is that it's not automated at all and Right. And it's slow. I think if you have like large data that you need to spin up and you also have a limited number of environments and that's not like, I think multi dev is great.

I think Pantheons great and we have a lot of customers that are hosted on Pantheon and still use tugboat and still use multi dev 'cause they'll use tugboat for the automation and having tugboat super fast no matter how much data you want in the previews. Which we can probably get into the nerdy bits of that later if we want to, but, but you know, so that, that automation is really like what creates like productivity for the entire team. Yeah. And then later if folks wanna do, like, let's say everything's merged in and they wanna do a smoke test of like, or say, say someone's working on a feature branch or something, and like lots of developers are all merging into this one feature branch that has like migration data or something like that.

And it's like, okay, well now let's spin up a multi dev and test this out on Pantheon and make sure everything's looking good there too.

John: Yeah. So that's kind of where I got to, as you were describing what tugboat did, like the secret sauce that you guys bring is that automation piece and the integration into the CI ICD process.

Right? Because ultimately, like if you were not using tugboat and decided to just try to do this on your own, you'd have to build yourself a whole lot of scripts to to, to bring that to the level at which you guys do it. So Yeah. And.

Nic: Sorry, I, I was just gonna say a, be, I think a better analogy is actually a platforms kind of whole setup.

Mm. Okay. Because, you know, one of the differences between both Aqua and Pan on Platform, one of the reasons why I like Platform is that every, when you create a port request, depending, configure it, caveat, caveat, whenever pull requests, it creates an ad hoc environment just for that pull request pulls on production, database backups and files and all that kind of stuff.

And there's ways to sync it. You are limited to the number of environments you can have, but you can pay for more. Right. You know, a lot of clients when we're doing development will pay for six or nine or 10 environments depending on how many developers are working on things.

Multiple: Mm-hmm.

Nic: Even though it's the same infrastructure.

I mean, there's still, I, you know, the clients that use tugboat also use Platform. So there's still reason to use Platform even with, yeah. Even with a, a closer set up to mm-hmm. How Tugboat works in general. Right. But Platform is probably the closest you can get. To having these multi environments outside of

John: yeah.

Outside of

Nic: using tugboat directly. Yeah. But I mean,

John: so it sounds like we're being, we're, we're, we're saying, well, James, you have a great company here, but there are other guys doing the same thing.

James: And

John: I wanna be very clear, like, we're not saying that, like, I think we tugboat,

James: it's a valid question.

John: Sure. We try to ask valid questions.

Yeah. Yeah. But like, but I think like the, the point is that I think where Tugboat excels past those other solutions, right, is that when you're a tugboat customer, and James, correct me if I'm wrong here when you're a tugboat customer, you're talking about customer, you have the ability to kind of like spin up these environments on every, every merge request, right?

Mm-hmm. So there's no limit to the, to the environments you can create. You can build it into your CICD process, which you can, you can, we already said that with these other things, but I think, like, the way I look at this is like. Tugboat is like a, every Mr sort of, sort of thing that's integrated into your CICD process and like multi dev or platform solution is more of a, Hey, we need to holistically see maybe a grouping of Mrs maybe a much larger feature.

Right?

Nic: I'm gonna, I'm gonna disagree.

John: Well, of course you are because you're a developer and you can do this, you can do all this stuff in your sleep, like for the average user, right? So

Nic: you're, you're partially right. Let, let, let's start there. You're partially right, so if you're on Aqua, if you're on Pantheon, you're any, on any other standard thing, you're a hundred percent right.

If you're on platform, you're not quite, not quite, because on platform you get as many, as long as you pay for them, you get as many environments as you want.

John: Yeah. But I mean, gets what I see, the, that gets expensive

Nic: if you're gonna do it on

John: every mr. Right? Like that doesn't

Nic: like, I mean. Honestly, I have some very, very active clients and almost all of them, except for one or two, get away with three environments, right?

Mm-hmm. If, when, when you have the speed, when you have the velocity, having two or three environments, you know, three test environments is enough. But, but here, here are the reasons why we use tug. 'cause we have, I have clients on platform use tugboat, and what I would say the three defining characteristics or like three big things that the reasons why we're still using tugboat.

One is speed. It builds significantly faster than platform. Orders of magnitude faster. Two, support, like platform support is good. Tugboat support is stellar. I mean, you guys still have Slack and mm-hmm. Respond. I mean that when and when Platform had that, I would, I would've rated you guys equal. But now platform, they have a discord, they never reply.

Yeah. You have to open a ticket and mm-hmm. The ticket they're gonna take. An hour to reply to the ticket, which generally is like, that's, it's acceptable as far as support goes. I'm not saying that the support is bad, but it's not, you know, it's not at the level where you send a message in two minutes later somebody's replying.

Right. And then the third, the third thing is well, I guess it's kind of the same thing, but tugboat spins down environments once they're inactive for a while, resuming it is so fast. So the resuming environment, tugboat takes like. Five seconds, you seconds,

John: you realize you're literally making my case for me.

Right. Because like, like you have three environments that might work for your client. Right. But, and, and Nick is about to ask a question about kind of your client base and how they're using tugboat, but like when you get to much larger projects, much larger companies, like an MR could be open for like a month and QA could be backed up and not able to look at it.

Right. So having the ability to say, Hey, we put this Mr in, here's a tugboat instance. You can get, get to it when you get to it. Right? That's a good point. Yeah. Like, it's there, it's ready to go. And plus all the stuff Nick just said, like you're spinning down environments. Mm-hmm. You're spinning them up quickly.

Right. You're not actually incurring extra cost other than, you know, whatever the monthly or annual fee is for tugboat. Yeah. To, to, to have those environments and have it just work, right? Mm-hmm. I mean. Yes, as with Drupal, as with almost anything, there are a bunch of different ways you can go about building a solution, but like, from where I sit, like I would much rather pay James and his, his group of, of married developers to build a solution that, that is going to do all of the things I needed to do and, you know, do it, do it very well and continue to evolve

Nic: that there's another, there's another advantage too, by the way of using tugboat, which, which is that it helps you unlock a bit your dependency on the host, right?

Obviously Drupal can be hosted many different places

Multiple: mm-hmm.

Nic: Many different ways. And each, each of the big three have different ways of providing different environments and stuff, but Right. If you are using tugboat as a service, if you have to switch from platform to Aqua Awkward or whatever. For some reason QA and the end users see the same interface and the same Yeah.

Like they're using tugboat and they're, they see the same, you don't have to like, do anything. You just

John: I actually have a question. Same. I have a question around that. Sure. Right. So James, like, in theory Nick is correct, but as we all know, different hosting vendors have different configurations for their

Multiple: uhhuh,

John: for their platforms.

Do you, do, does tugboat have some way to kind of mirror those configurations? So what I mean by that is like, you know, I don't know let's, let's put and this is gonna be really high level and I'm, I'm, I'm doing it on the fly, so it might not even really make sense, so bear with me. But let's imagine like your, you're trying to validate something in the caching layer of your application, right? Mm-hmm. And you, you know, aqui is using CloudFlare Pantheons using Fastly, right? Mm-hmm. Like if you were using tugboat and you said, oh, we need to make sure that the, the thing that we're spinning up is gonna be correct on a certain hosting platform, do you, do you have like kind of those, those I don't know, recipes to use a Drupal to kind of create that specific environment?

Or is it simply just like, Hey, d devs chilling, chill in there and whatever your environment is like, we can spin that up using, using that containerization. We're getting to kind of in the weeds here, but I, I'm just curious.

James: Yeah. There, I mean, I don't know if the, the CDN example really tracks 'cause we don't have any sort of CDN in front of our environments and so, right.

Yeah,

John: it was a pretty, it was a pretty terrible example. I was just No, I mean, it's, it was the first one that came to mind.

James: Yeah. Yeah. But but to your point there, each, each hosting provider is gonna do some things different and there would be some work in your process. You know, if you were, of course there'd be a ton of work if you were moving from one host to another.

And so example for if you were hosted on Pantheon and moving to Acquia or vice versa, you would have you know, for on the Pantheon side, you'd be using like Terminus commands to pull down a database. And on the aqueous side, you'd be like using the what is it, A CLI or something like that?

Yeah, their aqueous CLI. Yeah. To pull down a database stump. So in your tugboat configuration, you'd need to modify. How are we getting our database stumps? And that's gonna change and you know, from host to host. But otherwise you still

Nic: have to, you still have to validate on the actual environment too.

That's why. Yeah, that's why even after you merge mm-hmm. On tug on the tugboat side, you're still testing upstream. Makes sense. Yeah,

Multiple: yeah,

James: yeah. And you know, there's, I

John: withdraw my ridiculous question. That's not ridiculous. '

James: cause I think there's, there's gonna be work. I think that to your point though, like, Nick, this web development agencies.

Love having tugboat because they're working with all these different clients that might host in various places, right? And so they can have a standardized workflow for their entire development team and their QA folks and their project managers. They can say, this is the way that we work. Like, and we've, we can streamline how we use tugboat.

We can streamline how we're using our local development tools. And we can actually, like, they, they'll also are able to get started on a project before hosting decisions are even made. 'cause a lot of times you can land a gig and then you're still like waiting for hosting the hosting contracts to all get signed and stuff.

And you're like, oh my gosh, this is fixed bid. We've only got, we've got a fixed deadline here. And the development team is just sitting around twiddling their thumbs because there's no hosting yet. Right? No, but, and it, but with Tel, yeah,

Nic: it, it also consolidates the. That piece of the setup too. Right? So if, if something happens on tug boat or some, you know, some, like recently we had an last week, two weeks ago, we had an issue with something with my sql.

It just wasn't building properly anymore. Just

James: my, my SQL upstream made some changes that required

Nic: SSL. Yep. And so we, I fixed that with one client. And if you're using tugboat with multiple clients, you see that same error. Well, now that knowledge is transferrable. Mm-hmm. Right. You can, you can fix that everywhere instead of having to, whereas when you have a client building using Travis, another one using this, another one using that, and another one using custom bespoke, another using Amon.

Mm-hmm. You have to debug each environment, each setup, and each syntax differently. But tugboats let, lets you kind of standardize them. Yeah, for sure. Okay. So. That's question two. Moving on, I do see that on on the website that you're support, you do support some rather large companies, NBCI, bm Spotify. Can you tell us a little bit about who your, and you've mentioned agencies who Yeah. Who is kind of your core client base and how do you see them using tugboat?

James: Yeah, I need to update some of those logos on our little logo wall there.

'cause IBM's not using tugboat anymore. The, they they were using Drupal for a while and then switched to Adobe Experience Manager. And actually we had tugboat running with a EM for them. And the Adobe folks were very unhappy about that. And so they kind of like. Elbowed us out of the room and you know, what are you gonna do?

They got lots of money and lots of folks. So, we were, we were sad to lose them, but I do need to update that that logo wall. But yeah, you know, like I said, I, I think I get a lot of these big brands because of the agencies that we're working through, we're working with. So I think agencies are our primary you know, market that really sees the value of tugboat and gets it.

And and then through that. Once the, once their clients see tugboat in action, they're like, I can't imagine working any other way. And so they just keep using it after that. So, so yeah, we've got, you know, kind of a wide array of actual organizations that are using from federal, state, local government, higher ed, large media, like you mentioned, NBC and FinTech healthcare.

There's just kind of like a, a broad mix of, of folks that are using it.

John: And it, it sounds like your agency partners are, are they reselling it, is it part of their basically tech offering where they say, Hey, we come with our developers, we use Git, we use tugboat, and then we integrate with whatever hosting provider you wanna, you wanna use?

Is that kind of the, the idea? Yeah.

James: Yeah. Some of the agencies will, you know, kind of pass through the cost along to their client, right? And some will just pay for it 'cause they see the value in for their own organization. And, you know, sometimes, like when you're working on these big contracts, it can be really hard to add anything that gets a, a line item is something to negotiate over.

And you know, so if you can not have. Another line item and then them be like, well, we, we don't want tugboat. You know, 'cause we don't even know what that is. And you're like, well actually, you know, we don't wanna work without it. So, yeah. You know, like, so it's just different organizations kind of, kind of do it different ways.

I would say most people, most agencies pay for it themselves because they, they see the value of it.

John: And so, I, I don't wanna dive too much into pay structure, but like, so an agency can buy, can buy tugboat and then kind of use it on multiple sites and projects if they would like

James: Yeah. Yeah. So you can have one subscription and then set up permissions sort of on a repository level so that so that, you know, different repositories, like if you've got contractors that only need access to a few different projects, you can you can invite them at that level.

So, yeah. Got it.

Nic: You can even use email to log in. I wanna say I appreciate that you don't e even though it's like down at the bottom of the list under an order, it's not Yeah. Un under a, a lot of websites that do that, like it's a, you have to click something separate to log in by email. I appreciate.

Oh,

James: that does frustrate me. Yeah.

John: So, so I mean, I don't wanna say tug tugboat seems pretty straightforward, right? Mm-hmm. As far as the use case, right? It's taking, taking your, your merge quest, it's building an environment, allowing your QA teams to te to, to test those and see those kind of like in real life, if you will.

Yeah. I'm, I'm wondering if you can share some you know, interesting use cases, unique use cases, maybe where somebody's using tugboats maybe not in the way that you would normally think about using tugboat.

James: Yeah, I mean, a couple things come to mind. There's a lot of folks using it to spin up demo environments.

You know, they've got a product or they've got a tool or something like that, and they want, they want a button on their website that they click. And then you have an environment that's an isolated environment where you can like test out their tool. So like Drupal decoupled, for example, is using tugboat under the hood for their demos.

And so they, you know, they can use, you can use our API to spin up these environments and really all you need is a, a repository and an API token, and then you can sort of like create sandbox environments for that. So, so that's a good use case. That's not the primary use case, not something that we initially thought of when we were building it.

So creating those demo environments and then. You know, I don't know if you've been on a drupal.org issue recently, but for a merge request when it gets created now, we're, you know, over the past few years we've been spinning up environments, testing environments there as well. And that's, so any module, any theme, Drupal core itself, if you've got tugboat wired up on a, on your contrib module or contrib theme you can get a environment that spins up for that merge request automatically there.

Nic: Hmm. I do have a question about that though.

James: Yeah.

Nic: So that's for every merge request, right? It's not optin,

James: it's optin in the sense, like for a contribute theme or module if you don't have, I'm sorry, for core. Oh, for core, yeah. Yeah, it is.

Nic: It's because that's something I've been meaning to open an issue for because yeah.

There are certainly ones where you want. Mm-hmm. Right. Especially front end changes or if you're trying to test something, it's useful. Yeah. I'll be honest, there's a lot of poor requests that I do, especially when I'm like, hammering something out on the backend. Yeah.

James: Like it doesn't need a, it doesn't

Nic: need a, it doesn't, it doesn't need, I love a way to be like, Hey, dis this for now.

Right. And then, or, and then not use those resources. Right. Because I don't wanna use your resources or tugboats resources when it's not providing value for that particular issue. Yeah. I imagine part of the reason why you do, it's that people can be aware of how good tugboat is and get exposed to it.

I mean, but I mean, it's,

James: it's more that it's a complicated problem to solve how to get it like an opt-in or an opt-out sort of thing. Because drupal.org. The whole project and issue Q on triple.org is complicated, you know? Yeah. And yeah, the different categories and tags and stuff and, you know, I don't know, do, it's far

John: easier to give it to everybody and then down the road figure out how to reduce it than to try to like start from there.

Nic: Can you detect when people visit it the first time and build then, because it builds fast. And if somebody just doesn't Hmm. That's an interesting idea. Environment. Don't, yeah. Don't build it.

John: This sounds like a, a great conversation to have on Yeah. al.org issue.

James: I would love to brainstorm this for sure, because, well, I, I will say though, like tugboat is very efficient with its disc usage and resource usage and stuff, and, you know, it does spin the containers down.

So there's also a part of this where it's like, is the juice worth the squeeze sort of a thing, you know? Yeah. With like, how much effort would this take to develop versus like. We we're, we're fine on the resource side of things, but it is something if, if we did think of some elegant solutions that worked really well for the community, I'd absolutely be interested in working on that.

So,

John: so question about our, our question about my last question. We talked about good use cases. You talked about people using it for product demos, which is super interesting to me. Yeah. You talk about being already being integrated into the Drupal issue queue, which is super helpful to the community.

Thank you for doing that. Mm-hmm. But I wonder with the idea of a marketplace coming in, the idea of site templates coming mm-hmm. Could there be a, a future, a future feature where you can demo a site template via tugboat?

James: Absolutely. I mean, it wouldn't take much to do that. And I, on on the same, by the same token though, like I, I think the.

Drupal Forge folks are very interested in providing that as well. And I don't wanna step on anyone's toes there. So we're, you know, I don't know, I don't know how to, to navigate that. I guess. I think it would be like the DA already has a tugboat subscription that, you know, they're getting a, a hefty discount on.

It's basically just like the cost of the server. So we could, we could al already integrate with that subscription and not, you know, not have to do anything extra. And the API endpoints are there, we actually did this when Drupal CMS first came out. We created a little landing page that was like, try Drupal CMS and behind the scenes it was just, you know, using.

The D oh subscription as it was, and, you know, just cloning a cloning, a preview basically. And it spins up in a few seconds. So

John: I, I will say and I don't, I don't want to go too far, too far down this really deep hole, but I will say that like, I appreciate the ideation and I appreciate the, the competing services in the Drupal space.

Right? But I also feel that like. From a Drupal Association standpoint, from a Tim Lennon's team managing services standpoint, like we need to simplify, right? So if, if tugboat is already there and tugboat already has the servers and the connections and the APIs set up, like,

Multiple: yeah,

John: let's just, let's just make that easy for everybody, right?

That doesn't mean that you can't go to Drupal Forge and, and, and try a site template on your own. Mm-hmm. And it doesn't mean there can't be multiple options. But Yeah. I mean, I would say like, yeah, to make everything easier for everybody. If I were the supreme leader of, of Drupal, I would say like, Hey, let's, let's do, let's, let's make things easy.

Yeah. But anyway, that's, that's my thought.

Nic: We've heard a lot of praises for tugboat. If I, if I'm listening to the show and I'm thinking of something that I should start investigating, are there any use cases that I should be aware of that might be trickier for tugboat or maybe outside of, Hmm. Because you said you integrated with a m so it sounds like it, it's not even like it has to be Drupal.

Yeah. It sounds like you support other technologies too. Is there, is there something in particular that might be something worth bringing up early on in a sales call?

James: Yeah, well, yeah. So, in, I was just at word Camp US a few weeks ago and I was shocked at the number of big brands there that do not use version control.

Lemme tell you whose fault that is. Well, I don't, I don't, I'm just, you know, I, I don't have any sort of criticisms more just like, wow, that's, it was just shocking to me. And there's a lot of teams that are developing these really big websites in browser, you know, like clicking around mm-hmm. And installing plugins and that sort of a thing.

And so I would say, I guess if your, if your team likes to work that way, where we like to have a staging server where we go and we, we click around and we do things and then if we like it there, then we push it to prod then tugboats probably not gonna work. They're not really gonna improve your workflow.

And in fact it might, well it might reveal some, some issues with your workflow. Yeah. Which it would, from my perspective would be good. You know, 'cause you would see like, wow, you know, syncing databases across these environments is really tricky and maybe we should think about moving content. Down and moving config up and you know, that sort of a thing.

Nic: Well, that, that, that, that right there is the root of the problem. Yeah. WordPress architecturally expects you to make changes on production and expects to be able to make changes on production. Yeah. So yeah. Yeah. Nevermind moving config. There is no config. Mm. Right. And databases are meant to be modified.

In fact, even just using something as simple as composer is very tricky. Mm-hmm. Because, yeah, there's not only there plugin, are there plugins that don't support composer? There are plugins. When you put the key in for the paid version, they download a copy of the files for you. Yeah. So like, they basically replace themselves on disc once you put a valid license key in.

Mm-hmm. And. For environments like platform sh where it's read only, you can't even use those because yeah, you can update locally, get the new files, commit those, push those up, do a bill.

Multiple: Yeah.

Nic: A lot of those plugins that protect themselves that way check to see that it's writeable and check to see that the license key is there before it runs.

And so you end up with a chicken and egg situation where you can't enter the license key because it can't write to that environment, but you also can't deploy the code because the code will then check to see if there's license key and it's not valid. It'll break the site. Yeah. And so, so there's plugins that you literally can't use in WordPress because, because of the way that they're expected to be set up.

Yeah. So yeah, I could see that being tricky for tugboat as well.

James: Yeah. There, and there are some, you know, there's, there's definitely plenty of WordPress folks that are using version control and are trying to create like a robust development process and just having unfor, unfortunately I'm one of them.

And so we've, we, we do have a lot of WordPress folks, but I, yeah, I guess that was just what came to mind is like, yeah, if, well, just out of the gate, if you're not using version control, tugboat will not work at all. But if, even if you're using it sort of like minimally and you have this process where a lot of things happen in the database, I'm not sure you're gonna get the value out of tugboat that you would otherwise.

John: So let, let's, let's dig into that a little bit. So, say I'm, I'm a person listening to this podcast and I'm like, wow, James seems like a nice guy, and tugboat seems like a great company and I would love my QA team to be able to use, use something like this, right? And, but I'm not overly technical like my developers are.

Developing somewhere over there or somewhere over there or whatever. What is, what is the setup for, for tugboat look like? Say I go in and I buy, you know, I pay for it. I, I buy, I buy a subscription. Um mm-hmm. Like how is the, how is, what's the onboarding process like now? Assuming I have a, you know, I have a GI repo yeah.

Like, do I need a developer to like, be kind of like boots on the ground to like get this thing up and running?

James: I think you'd probably need a developer. But we're also, like Nick said, we've got pretty fantastic support, so we're also happy to hop on a call anytime and help folks get set up. But yeah, for folks that do s do some more work on the development side, getting tugboat set up is similar to like writing a docker compose file or something like that, where you, you need to have an understanding of what services you're running.

How do I get. Data in and out of these services. Mm-hmm. How do I build the Drupal site? You know, like in terms of running database updates which is usually like running DR commands and stuff like that. So if all of those things are words that you're not used to saying very often, then you'd probably want some help.

We do have some like trusted partners at well as well that can come in and like do like, more than just help you get tugboat set up, but get a whole CICD automated testing, you know, enderman testing getting set up as well. I'm sure Nick can do that work as well if, I don't know if he has availability, but if folks were interested in that, so, absolutely.

Yeah. Yeah.

John: So that, I mean, that's interesting to me. So basically you are connecting into the get repo. Mm-hmm. Via, via webhooks or what have you. And then, and then there's a file in the, in the repo that's like, Hey, here's the configuration for tugboat. Yeah, exactly.

James: Once

John: you, once you get pull that repo, it starts going through and doing all of the steps to kind of build that cycle.

Yeah,

James: yeah, yeah. Exactly.

John: All right. I mean, that's, that seems, and there's some

Nic: templates and things, so it, it's pretty straightforward.

James: Yeah. We got docs dot tugboat qa.com. We've got lots of starter templates and documentation there. And some of it might be a little outta date with PP versions and stuff like that, but for folks that you know, know what they're doing, they can just catch that stuff.

Pretty cool. I think we had, like some recently some PHP 7.4 stuff still in there. We're like, whoops, we gotta update those

Nic: templates. So, well, I, I, I still go to tugboat qa, so,

James: oh yeah, that's right. That's a whole other story of the domain fiasco.

Nic: Yeah. So, John, before, when, if you ever, if you ever come up with a unique domain, you might wanna ask James someday.

Yeah. But, well, well let, let's not leave our listeners hanging. W let's talk about it now real quick. Okay. What happened with Tug Boat qa? Okay. Yeah. So this is a pretty clever domain.

James: Yeah. So we had our, our primary domain initially was tugboat qa, which QA is a country code top level domain. And it's associated with the country of Qatar.

Or some folks pronounce it Qatar. And everything, you know, it was, it was great for many years. We had that domain. And then the short story is that all of these country code domains are, are basically like sold through resellers and there's an, there's like an agreement that they have with the actual registrar based in the country.

The particular registrar we were with, which I don't wanna say because I'm worried that I'm gonna say the wrong registrar and throw someone under the bus that I don't intend. 'cause it was a pretty commonly sounding name. 1, 1, 2, 3, something, something. Behind the scenes, we didn't know this, but they were their negotiations with the country of cutters, registrar fell through and suddenly the lights went out across the board on all of our domains.

And so this was like on a Sunday afternoon while everything was down. And so we tried to reach out to the registrar and they're, for days, they're just like giving us the runaround, not telling us what's going on. And then eventually the primary registrar, like the, you know, I reached out to, to the actual country registrar and they told me what was going on is that they basically fired this reseller and they were like, we're not gonna work with them ever again.

And so they helped us transfer it over to another registrar that, that we're working with. So, so yeah, that was somewhat of a nightmare and has definitely given me pause on using country code, country code top level domains. So a lot of, back to actually back to the Shirley module, a lot of the short, your all services are, anytime you see a two letter is usually a country code top level domain.

Nic: Yeah. Or just looking at

John: those myself.

Nic: Yeah. Yeah. And, and that can cause problems too. Like with the.io that might be going away.

James: Yeah. Dot io. There's a.ci, there's a, yeah. Cm, we talked about a lot of those. They're all countries under the hood, so,

Nic: okay. So tugboat, I, I think the reason why we ended up actually inviting you to be guest hosts was because I found out recently that tugboat had split off from Lulla Bot originally.

I think it originally started as a service into Lalla Bot. Mm-hmm. And then became kind of a public service from Lalla bot and then became a company, and then recently was, was completely spun off. Can you talk a little bit about maybe the why and the how and, and maybe when

James: Yeah.

Nic: When that happened?

James: Yeah. So the change is recent. It was so it's September now and, well, it feels recent to me, but it was beginning of June was when we spun out on our own. And the why is. Complicated and long. Actually, it's a long story, but you know, maybe some history here. So yeah, tugboat was created I, I worked for Lulla Bot for 15 years.

And about 12 years ago I was working on a project for Intel. And we had this situation where we had a super sharp stakeholder there who was also very busy managing like five projects at the time. And and you know, we were trying to get this work done and get them to approve it. And the way that we didn't have host, again, back to the hosting issue, we didn't have production hosting yet.

So the only way that they could review our work was they would have to check out our code and, and get a local setup on their own machine or us screen sharing with them of our, of our own work. And, you know, there's time zone differences and busy schedules and all that stuff. So, long story short, you know, we created tugboat at that point.

That was, it was the duct tape and bailing wire edition, which is to say it was like Jenkins and Bash scripts, and it took forever and it was very fragile, you know, and we're like having to manage these Jenkins plugins and stuff like that. And, you know, we've, we've outgrown that at this point. But that was the beginning, you know, forms of, of what later became tugboat.

And in 2018 was when, you know, we really started like, okay, this. Like it 'cause it transformed the way Lubo was working. Like across the board, we were just like, we're doing this on every project. And once we saw it in action of the ability to test everything before code gets merged in, we were like, this is, you know, just a, you know, cliche game changer.

It really was. So, so yeah. So then in 2018, the, the leadership at that time for Lulla bot was like, let's turn this into a product. You know, like, let's, let's get out there and sell this 'cause this is like incredible and other folks need to be able to use this. And so, started building. That was, you know, around the time that No JS was really popular, Docker was just getting like, you know, really popular as well.

And so we're like, okay, we're gonna use no js, we're gonna use Docker we're gonna build this the right way. And that started, I think, actually in 2016 is when we started doing all that work and launched it in 2018. And fast forward I'll just, I'll just like put a headline over a very complicated series of events, which is just to say that running a business inside of another business is, is difficult.

So having, you've got Lulla Bot is a, a web development agency and so it's primary, it's primary business is services, you know, it sells time and materials or fixed bid projects. And it has developers that, you know, when they're. When they're working, we're getting paid, and when they're not, we're, we're not getting paid sort of a thing.

And tugboats a very, it's just a completely different business model. It's like, it's the, it's the slow. Like you get a customer and you're gonna have 'em for, for years, you know? But it takes a lot to get a customer, right? And so, selling having those two businesses run under the same overarching business is challenging, you know, and it's, it's basically like a startup inside of another company.

And we may get into this some more later, but also in 2020, I believe Lubo became employee owned maybe 20 21, 20 22. I might have my, my dates wrong on that, but and that really changed things as well, fundamentally changed things because in ways that we didn't predict in employee owned company.

Acts in the fiduciary interest of the employees, and there's a, there's a whole sort of like set of checks and balances for that sort of a thing. And so you've got a trust that's formed. You've got a trustee that you need to report to. You've got a board that you need to form and report to you as well.

And all of the, all of their eyes are looking at the bottom line and what sort of, where's the money going? Because it's a retirement engine for the employees. So like, if. If the leadership is not making wise choices with money, then it's there. It's the board and the trustee's responsibility to, to act in the interest of the employees and say, Hey, these folks are not doing what they should be doing for your best interests.

So, you know, you can imagine having a startup inside of that environment is very difficult to make the case for like, Hey, for me over here in the corner going, can I have some sales and marketing budget? And trying to get that, it's difficult because it's like how do we justify you know, putting.

More money into this thing that's already not profitable, sort of a thing, you know? And, and, and here on my end I'm like, well, it could be profitable if we get some more sales and marketing budget. You know, so it's like, it was, it felt like this catch 22 it, it,

John: it was probably about time for it to kind of like spread its wings and, and go do its own thing, right?

James: Yeah. And, you know, the other factors just in the market in general, in the beginning of 2025 here, we've, we had with the new, with the administration change, Lulla bot had some big contracts that that all fell through at the, at the beginning of the year. And I know many other web agencies as well were, were affected.

And so you've got. All this like outward pressure that was unrelated to tugboat, that was like, we're looking really hard at the bottom line now because of all this stuff. And so, you know, Lubo had to do a reduction in force and really tugboat was a part of that reduction in force. Like us spinning out was a way to like solve that problem for Lulla bot.

So it just took a lot longer.

John: Just, just for, just for our listeners, if you wanna hear more about Lulla bot and employee owned companies there'll be a link in the show notes to episode three 90 where we, we talk to Seth, who is the C of Lubo.

Nic: So one, one quick follow up question then about that. So Lubo was employee owned tugboat, is that employee owned?

Is that

James: It's not so was it before? It was, yeah. So it was, it was wholly owned by Lulla Bot, so therefore it was employee owned. So it wasn't, it, it, it had a separate entity you know, based in Rhode Island, just like Lubo. And but that entity was a di what's considered what's called a disregarded entity.

We're getting into like, nerdy business stuff, but but but yeah, so Lulla bot owned Tugboat.

Nic: Okay. Is Tugboat FedRAMP compliant or like HIPAA compliant? Like, a lot of my clients have a lot of compliance. Yeah, yeah. Letters that they need, all those compliance. Is, is tugboat compliant with any, all, some, depending on

James: It is, it is not.

So there's, there's various like compliance, you know, there's SOC two, there's hipaa, there's FedRAMP, FedRAMP from what I've heard. Anecdotally is very, very expensive to get FedRAMP certified. We do a lot of work with organizations that require FedRAMP compliance, and the way that works is they host tugboat internally on their own FedRAMP managed bound within their own FedRAMP managed boundary.

So,

Nic: oh, because it's all Docker based and no jazz, right?

James: It's, yeah, it's all, you know, under the hood, it's, it's, it's just like if you were to, you know, be using d dev for development, it's, it's pretty similar in that respect, you know? So yeah, you can, you can host it in on a, on a FedRAMP. Ho compliant host.

And then if it's a managed environment, then, or if, you know, you've got a team that's managing it themselves. So that's, that's the way we've done that. It's definitely something we'd be interested in. But right now, you know, we're just getting started and we're like, okay, we've, you know, if, if we get to the point where we'd probably need to get outside investment, if we were gonna do FedRAMP, and, and it, it is one of those things that I wonder, there's, there's a certain mentality that we had with tugboat for years, which was the sort of like, if you build it, they will come thing.

And just because we did all this work to become FedRAMP compliant, I do wonder if that, you know, will immediately open the floodgates of like us being able to then pay back the debt that we incurred in that process. Or if it, you know, maybe it would, I don't know.

John: Or, or even just a, a partnership maybe with a FedRAMP compliant host.

Might be, might be a better, better way to go about it. But yeah,

James: there's, I am talking with a, drupal Agency Omo about you know, like they, they've told me like how, you know, just recently about how like GSA schedules work and stuff and about how we could get on someone's GSA schedule and then they could effectively become like a reseller of tugboat under their GSA schedule.

Which does make it easier on the procurement side of things. Yep. That doesn't solve the security compliance side of things necessarily. We might still have to go through some security reviews and stuff, and we do that all the time. We're happy to do, you know, security questionnaires and provide any sort of information that security compliance teams need in order to, to feel good about the purchase.

So.

John: Okay. Two minutes for our last question here. All right. So, at conferences you guys hand out tub goat stickers. It's a sticker with a goat in a tub. Yeah. Why is that?

James: Yeah, so, excuse me. Couldn't get to mute mute fast enough. That's okay. When we first named Tugboat Tugboat we kept tying it as tug goat and and so that just kind of ended up becoming our mascot.

We just kind of leaned into it and you know, we like to keep it fun. So even if you hit like a 4 0 4 page on our site, you're gonna get a picture of a goat in a tub or something, or if you hit an arrow page or something like that. And so, yeah, we've had had various iterations of the goat in the tub over the years where I like to hire different artists that, you know in fact, if anyone was at DrupalCon Atlanta.

I commissioned a, a famous local Atlanta artist, a street artist our land to do a goat in the tub and did a giveaway at the, at the lulla bot tugboat booth for winning that artwork. So, so yeah, we just like, you know, like to keep it fun where we can. So, yeah.

Nic: Alright, James, we're nearing the end of the show.

Thank you for joining us. The last four, well, five weeks I guess, but there was a gap in there. Yeah. Yeah. Thank you for joining us.

James: Yeah, it's been, it's been really fun. Thanks for having me.

John: Do you have questions or feedback? Reach out to talking Drupal on the socials with the handle talking Drupal or by email with [email protected].

You can connect with our hosts and other listeners on the Drupal Slack in the Talking Drupal channel.

Nic: If you would like to be a guest on Talking Drupal or a new show TD Cafe, click the guest request button in the sidebar on talking drupal.com.

John: You can promote your Drupal community event on Talking Drupal.

Learn [email protected] slash td promo.

Nic: Get the Talking Drupal newsletter to learn more about a guest host, show news, upcoming shows, and much more. Sign up for the [email protected] slash newsletter.

John: And thank you patrons for supporting talking Drupal. Your support is greatly appreciated.

You can learn more about becoming a [email protected] and choosing the big become a patron button in the sidebar.

Nic: Alright, James, if our listeners wanna get in touch with you, what's the best way for them to do that?

James: Yeah, I mean, you could find me on LinkedIn. Like I mentioned we've got, we've also got Slack support like Nick was talking about.

So there's the tugboat slack. If you're on Drupal Slack, there is a tugboat support channel in there as well that I'm in if you need help with any of the D oh, side of tugboat things, so,

Nic: yeah.

James: Awesome. John, how about you?

John: You can find me personally at picozzi.com You can find me on all the major social networks and drupal.org at John Picozzi, and you can find out about EPAM at epam.com,

Nic: and you can find me online pretty much everywhere at nicxvan at N-I-C-X-V-A-N

James: Well, hey, if you've enjoyed listening, we've enjoyed talking.

John: Thanks a lot everyone.