Transcription: OpenAgents Episode 129 - Hosting OpenPress

Source: https://x.com/OpenAgentsInc/status/1842353777816289527 Wiki source: https://raw.githubusercontent.com/wiki/OpenAgentsInc/openagents/Video-Series.md Media title: OpenAgents - Episode 129: Hosting OpenPress We spec out our initial plan for Open... Upload date: 20241004 Transcription model: gpt-4o-mini-transcribe Generated at: 2026-06-01T16:23:38Z

Machine-generated transcript. Review speaker labels and wording before using this as quote-grade source material.

[00:00] Speaker: So we've got a super basic blog here now. Before we go too much further on that, I want to talk about hosting. WP Engine makes $400 million a year hosting WordPress sites. I don't know how much WordPress.com does, but Automattic or whatever, they're a $9 billion company, aren't they? So hosting, this is super important, particularly if we're talking about services that agencies who are working with multiple clients are going to consider using. It's really important to get these kind of details in place. Now, to kind of scratch my own itch, I have both a project that I want to create a website for, the Atlantis Sports project, as well as I have clients currently or customers of OpenAgents who are paying me for agent work and also web design work that I want to have sites hosted that I can manage on their behalf or give them access to. So I'm interested in solving this first for myself. So there's some urgency and we're going to be building this out rather rapidly because I want this right now. So I think at the top, and my information about the WordPress ecosystem is rather dated, but if I remember correctly, WordPress.com is sort of their managed hosting offering and then the .org is like open source, nonprofit, something, something. So somewhat similarly, OpenPress.ai, that's where our main webpage is. OpenPress.ai, that's live now. So in addition to being sort of like the introductory information about the project, you can also log in and this should be where we have managed hosting. So when you log in and you go to the dashboard, you should see like a list of your sites that you can then manage and deploy from there. Alternately, you can always self-host. The code is on GitHub. It's under Creative Commons Zero. You can always pull this down. Eventually we'll add different little instructions and, I don't know, installation scripts to help this, but it's a standard Laravel project. You can pull this down anywhere you want. And then I'm thinking that, you know, some people will just want a site for themselves. If you're an agency, then, you know, we'll have some little multi-site flag in here that will let you turn any single install of OpenPress into a multi-site install of WordPress, potentially with multiple domains. For the kind of infrastructure piece of that, you know, I definitely don't want to be building all of that from scratch, but fortunately, Laravel Forge is like the official hosting solution, kind of. It's not really a hosting solution. It's like an orchestration layer on top of different cloud VPSs. I use this for all of my stuff. The SSL and the security and the blah, blah, blah. It's great. It's like from the Laravel project. And they have a really good API. I haven't used it, but it seems very thorough. So anything we need to do with SSL certs, SSH keys, sites, servers, blah, blah, blah, blah, databases, there's APIs for all of this. What the heck? What's this WordPress thing? You can install WordPress. Whoa. Okay. So kind of the idea here is on top of the Forge API, we want you to be able to manage all of the like, just the basic stuff that you need for your website via OpenPress.ai and know that you don't need to go and learn a bunch of like Laravel specific hosting considerations. You don't have to learn Laravel Forge. You can if you want to, if you want to sign up for your own Forge account, etc. You can do that. This is basically going to be designed to work with Laravel Forge, whether that's your account or the account that we have that we're, you know, charging you access for. Okay. So we have managed hosting or self-hosted. Both connect to the Laravel Forge API. The documentation is there. So let's skip down to the bottom here. You can create any server. Basically, it's any Ubuntu 24 server. There's kind of connections for DigitalOcean, Akamai, AWS, Hetzner, Volter, or any custom VPS. You just give it the access credentials or whatever to give Forge access to do what it needs to do. But it basically provisions you PHP, Nginx, your choice of MySQL, Postgres, or SQLite, etc. We'll probably use MySQL just because that's what people from WordPress are accustomed to. Redis. So you can easily with like a click or two deploy a server that goes to one of these clouds. You can always edit the raw server in the raw cloud. If you're using our managed service, you don't have to care about any of that. We'll be running it on the infrastructure that we're paying for it, AWS, etc. But if you're doing this yourself, you can create stuff at any of these, plug it into Forge. Forge will create you a server. On the server, you can have any number of sites. So, for example, the server that we have running OpenPress.ai. I can show you in here. I've got some client sites right now on this portal. And then so on the OpenPress server default. So there's the OpenPress.ai. It's linked to my GitHub repo. So you can set up auto deploy from the repo if you want to or whatever. And then you just add other sites in here. So like the next thing I'm going to be doing, ideally, in the next video or two or offline, is having the next website, which I'm going to kind of pretend is a client website, this Atlantis ports website, have that be a site that's in here on this same OpenPress server, but sort of mediated and managed via our OpenPress dashboard. So a server can have multiple sites. I might have like some client sites on this original server. And then if someone wants their own server, they can pay extra for that. Now, the cool thing, and I'm specifically intent on building this in a way that anything that I choose to run for managed hosting, I want you to be able to manage, do the exact same thing. If you're like, OK, you know, and whether it's weeks from now, months from now, however long from now that you think that the OpenPress product is like something that you would actually want to offer your customers. At any time in there, you can like pull down the code, deploy it on your own infrastructure, set up your own payments arrangement. There will be Stripe integrations and stuff using Laravel Stripe integration and such so that you can just like make money and you don't need any freaking permission from me. How do I like how do I make it so that I can't ever revoke the fact that you don't need my permission? OK, is this video legally binding? You never need my permission to do anything relating to OpenPress. It's in the public domain, Creative Commons zero. Just fucking do it. Public domain. Take it. Go do it. OK, is that good enough? OK, so that's, I think, hopefully clear enough. So let's do a little bit of scoping this out, kind of like we did in the last video where we went into the agent. We made a little doc. I made I started one, but let's kind of think through this together. So we're brainstorming hosting similar to WordPress. A technical user should be able to download the OpenPress codebase from this repo and install it themselves on any supported server. But anyone else has the option of hosting. OK, anyone else has the option of hosting one or more sites on their own infrastructure. Likely using a, you know, Laravel Forge, likely using their own Laravel Forge accounts in conjunction with server infra. They connect to that or other options. I don't know. OK, so relevant models. So in the last episode, two episodes ago, we did relevant models were like user and post and then unit test. User could be an editor. You can have many posts. So we'll do that here too. We'll say, yeah, user can have many sites. Feature test. User can add a site. User can see a list of their sites in their dashboard. Site has a... Let's see, when we create a site in Laravel, it asks for a root domain. Project type. Static HTML, Nuxt, Next.js. We're not supporting that. Maybe someday. Static HTML? I don't know. OK, so yeah, Laravel. Site has, you know, root domain. Or will you not know what the root domain is necessarily right off the bat? Public directory, PHP version. Yeah, the cool thing is that this is like a mature product, so they got all these options, which like, if you just want a site, you shouldn't have... Like, what's all this stuff do? And, you know, take advantage of my years of like clicking around Forge. And we'll just build a little layer on top of this. So let's say the site has a name. Name. String. Name. Required. String. Root domain. Optional, because it could be set later. OK, user can add a site. User can see a list of their sites on the dashboard. This uses the Shad. Did I pull over the table component? I did not. OK. Pull that over there. OK, so here's what I want to do first. First, let's do a little bit of brainstorming. We'll have our agent help us brainstorm. OK, so I'm going to grab the relative URL of this. I'm going to go to my agent. So I already said scrape this. You know, aside from the GitHub tools here, you can have a, we do scrape web page, which uses Firecrawl. Yeah. OK, so we scraped the doc page. I've successfully scraped it. So I'll say now read this and speculate here. Don't use any other tools yet aside from view file. What APIs we may want to use or other considerations. And then maybe we'll have it update the doc for us. What's

[19:59] Speaker: Look at user test and write the equivalent site test. Then update the site factory migration model files to make the tests pass. Write the tests, write the code that makes the tests pass, just, like, do it. I'll do git pull. I'll run the tests. If we're at green, we move on with confidence. Certainly, I'll start by looking at the user test.php file. Now, wouldn't it be cool if your website, you wanted to make a change for your own website, for a client's website, and let's just say it's been a month since you've touched the code. Your memory of what goes where or how things were architected is not fully in your brain, but your Pal Open agents have not forgotten. And they can say, oh, you want to make a tweak to that? And it's got a little knowledge graph of all the stuff that it's done in the past. It's got the whole repo mapped out. And I go, oh, sure, let me do that. Boom, bada boom, boom, boom. Let's make you people more productive so you can handle more clients, make more money, and share a little bit of that money with me. Oh, it's a problem with WordPress. You get these things that are like accumulate inertia over 20 years. And even if you bulk up large staffs of people where you can, like, you know, do stuff, it's still you're kind of locked on to a trajectory in some ways, vulnerable to innovation. OK, we've updated site factory model migration model files. OK, so first of all, before I pull that down, do all of my tests pass currently? One of them does not. Oh, because I think that I've truncated. Yeah, so I'll fix that. I'll have the agent fix that in a second. Watch this. OK, so let's run. What does it make site test? So let's run all the site tests. Oops. Laravel Sanctum has API tokens. User model. What happened there? Added Sanctum support for API tokens. Why? Sometimes it can just make some interesting assumptions. But if you're like, why'd you do that? It's like, oh, didn't know you didn't want that. Let's remove it. All right, so we have three passing tests. Site has required attributes. Name, root domain, GitHub repo URL is managed by WordPress. Site belongs to a user. User can have many sites. Great. And let's have it fix this other test. This is related to something else. Thanks. Now, can you please diagnose why this fails? Come on, get out of my face. Get out of my face, face. Copy relative path. Look at and look through any files you need to find relevant stuff. It's nice being able to say stuff and not need to be precise. Very fuzzy. So once this is all at green, we'll do a little bit of interface build out so I can see like users and sites in the dashboard. It's really nice to be able to paste in failing test output to a thing and just let it go look at the relevant files. I'm going to guess that this test has something to do with content being truncated after a certain length. The post controller looks correct. The issue is likely in the view file. View file is correct. Huh. Ooh, that's... There might be a JavaScript related... Oh yeah. Yesterday's stuff kind of did some weird JavaScript... At one point the agent yesterday like went off the rails and added a bunch of like crazy JavaScript. Because I was like, can you fix this thing? There's a flicker and it's like, oh yeah, let's add a bunch of JavaScript stuff, hides this and that. Okay. What is this? Quas magnum out esse. Oh, it's because there's BRs in there. Ah, looks like the transform added BRs. Just make our test expect the first sentence or something. Okay, so while that goes, let's think about... So we right now have this CRUD for creating posts. I can create a post and then I see a list of posts on the homepage. And we may as well do that similar code for seeing a list of sites and having a button to create a site. Except it shows in a different place. It shows in your dashboard. I'll just get this to green real quick. You're right. It looks like... All right, 31 green passing tests. Okay. Thanks. Now we want to add feature tests for being able to create sites. We need a button in the user dashboard and the auth user dashboard for create site and show that list. Add feature tests for that. I want you to read post controller, routes slash web, and everything else relevant to posts because... Oh, and post test. Because a lot of those same patterns can be directly applied here. So there's a level of detail that I need to specify to agents as I go through. But you could envision that a bunch of this can be... I don't know, better abstracted. Basically, I'm still steering it in ways that an agent or a different intelligence would be able to steer also. I think we're getting to the point where a non-technical person could do this same thing that I'm doing and get similar results. Like this is getting me. I'm probably three times more productive as a developer than I was a couple years ago. But having that level of agents being able to manipulate sites for you being a technical thing, but you being a non-technical person just being able to say, I want this, and to be able to have it say, oh, okay. I don't know. Site test. We need to implement the necessary routes, controllers, and views. Curious how many steps this will be. 1, 2, 3, 4, 5, 6, 7. It'd be really cool if this all just worked. Better be styled right. I got to get this text gray 800 out of there. Finally, let's create a view for the site creation form. It didn't give me a summary. Did it get cut off? Sometimes if it gets too long, it'll just kind of crap out. Fix it. Oops. OK. So unfortunately, I wasn't able to have it update a doc. And now the context is just too long for me to be able to continue that one. It's just a bug. We're not handling that well. OK, so in this new chat, I'll say fix this, please. Read. The validation rules for the root domain field are not checking for a valid domain format. Let's update it. It's so easy. Laravel has all these helpers that, like, I don't have to think about proper regex for validating that something is actually a URL. It's already there. This is some kind of error I don't know about, but it works. Let's see. Thank you for achieving. Blah, blah, blah. The test is still failing. OK. A little wordy there, sir. We have 36 passing tests. Now, what do you think I'm gonna see when I log into my local? What am I gonna see? What am I gonna see in my dashboard? OK, we have not run the migration, so we gotta do that. Create site table has run. Ooh, now that button does not look very good. It's a blue button. Your sites, you haven't created any sites yet. Should I create a site? I'm gonna create a site. Ooh, site name. White text, I can't see it. Awesome site, root domain. Should fail, maybe? I can't tell what happened. Let's try this again. Atlantisports.com, Atlantisports. Let's take a look at the network tab and see what happens here. Your sites, Atlantisports. Oh, yeah. Forgive my typo, but oh my gosh. All right, I got stuff for safes.com. OK, let's say update the styling of this. We'll update the styling of this. I'll do that offline. That doesn't matter. So cool, so to recap, here's how we're handling sites, site hosting. I might do a video next kind of connecting this to the Forge API. But we've got a pretty solid start here on implementing this. And then maybe we'll start in the next video connecting this to the Laravel Forge API and doing the things like for domain. Like I'm guessing that there's a way to expose the server IP to give the user the instructions for adding their domain. So my goal is in the next video or two to be able to like configure an OpenPress site at atlantisports.com explicitly through this interface. So, yeah, not too bad for two days work. See you soon.