Four invoices landed in my inbox the same week: Vercel, Sentry, Plausible, Better Stack. Added up, they came to $152 a month, just to host an app, know when it broke, see who visited, and get a ping if it went down.

None of those jobs are hard. They’re just scattered across four different companies, each charging you separately for the privilege.

So I moved all four onto one box. A $5/mo VPS, one install command, one binary doing all four jobs. Here’s exactly what that looks like, with the real thing actually running: not a feature comparison, not a pricing page screenshot.

What You Need

• A VPS with 1-2 vCPU and 2-8GB RAM (I used a $5/mo box, Ubuntu 24.04 LTS)
• SSH access to that box
• A domain, if you want a real custom URL (not required to follow along)
• Five minutes: the install really is one command

I run my whole setup on a Contabo VPS, solid price for what you get, and it’s what this whole post is built on.

The $152/mo Problem, Priced Out

Here’s what four separate “it’s just $20/mo” subscriptions actually add up to:

Each one, on its own, sounds reasonable. Stacked, it’s real money for four things that don’t individually need a dedicated company behind them.

Why One $5 Box Actually Holds Up Here

I’ll be straight with you: “run your whole stack on one cheap box” is a claim I’ve measured being wrong before. A different self-hosted stack I tested, Coolify plus Postal plus Mautic plus WordPress, needed real RAM minimums that added up fast. Coolify alone wants 2 cores and 2GB before you’ve deployed anything. Postal’s own docs recommend 8GB on its own, because it runs MariaDB and RabbitMQ next to its web and worker processes. Stack those together and you’re looking at two boxes, not one, closer to $15/mo than the $4/mo the pitch usually promises.

This is a different situation, and I didn’t want to just assume it was different because the marketing said so. The tool I used, Temps, a single self-hosted Rust binary, states its own idle footprint at around 50MB of RAM on its own homepage. That’s genuinely light, not a marketing rounding error, because it’s one purpose-built binary doing these four jobs natively, instead of four separate open-source apps glued together on the same box, each with its own database, its own worker process, its own idea of how much RAM is “normal.”

I went looking for that number specifically because I’d been burned assuming a lightweight-sounding pitch would hold up without checking. It’s worth doing that check yourself on any tool before you commit a VPS tier to it. The resource page is usually one search away, and it’s a lot cheaper to read than to discover you need a bigger box halfway through setup.

Why not just run the individual open-source alternatives?

You could. GlitchTip (Sentry-API-compatible) and Umami (a clean Plausible-style dashboard) are both solid, genuinely open-source options if you only need to replace one piece. I looked at going that route instead of an all-in-one tool, and the honest answer is: it works, but you’re back to running multiple separate apps, each with its own database and its own update cycle, even if each one individually is light. The appeal of Temps specifically is that it’s one binary, one install, one thing to keep patched, not that the individual alternatives are bad.

Setting It Up

SSH into a clean Ubuntu box and run one command:

curl -fsSL https://temps.sh/deploy.sh | bash

That’s it. No dashboard sign-up first, no credit card, no multi-step wizard before you see anything. The installer provisions Docker, a time-series database, and a Pingora-based proxy (the same proxy engine Cloudflare runs) automatically.

Once it finishes, you register your admin account and you’re deploying. No signup form, no credit card, no email verification loop before you can see the dashboard: the install script is genuinely the whole onboarding.

What you should see once it’s done: a confirmation that default roles were initialized, an admin user created, and a preview domain assigned automatically (Temps hands you a working subdomain immediately, so you’re not stuck configuring DNS before you can test anything). If any of those three lines don’t show up, something in the install failed silently. Re-run the script before moving on rather than troubleshooting forward from a broken base.

Block 1: Hosting (replaces Vercel, $20/mo)

Point your domain at the box, connect a repo, deploy. Here’s the real thing, actually live, not a staged screenshot:

That’s observability-starter, genuinely running on my own box, answering real requests.

Block 2: Error Tracking (replaces Sentry, $29/mo)

Temps accepts your app’s existing Sentry SDK. You point its DSN at your Temps instance instead of Sentry’s servers, and your error reporting code doesn’t change.

I didn’t just take that on faith. I threw a real error on purpose and watched it get caught:

That’s a genuine HTTP 500 from a real endpoint, and the app’s own log line telling you exactly where to go look for it.

Block 3: Analytics (replaces Plausible, $69/mo)

Analytics here means real request counting, not a JavaScript snippet reporting back to someone else’s server. Here’s a real count, pulled straight from the box’s own service log:

That number is real, counted from journalctl, not invented for this post.

Block 4: Uptime & Health (replaces Better Stack, $34/mo)

Temps runs its own health checks every 5 seconds, with a 60-second window before it acts. This is specifically its deploy-health and auto-rollback mechanism, not a separate uptime-monitoring product bolted on. Add a webhook and you get a ping the moment something looks wrong, the same job Better Stack is doing for $34/mo.

Is It Actually Safe to Expose?

I’ve been burned by this exact question before. On a different self-hosted tool (Coolify), I measured that ufw cannot close a port that Docker has published. Docker writes its own firewall rules ahead of ufw‘s, so a ufw deny on that port does nothing at all. I’d actually written the opposite assumption into a script once, and only caught it by testing instead of trusting.

Temps avoids that specific trap by construction: its control-plane runs as a host systemd service, not a Docker-published port, and every deployed app routes through its single Pingora proxy rather than individual host ports. There’s no equivalent Docker-published admin port here to accidentally leave open.

Common Mistakes (and How to Avoid Them)

• Assuming every self-hosted stack fits on one cheap box. It doesn’t. I’ve measured a different stack that genuinely needed two boxes. Check the specific tool’s real resource numbers before you commit, don’t assume “self-hosted” means “lightweight.”
• Trusting ufw to close a Docker-published port. It silently won’t. If a tool exposes its dashboard via docker run -p, firewall it at the DOCKER-USER chain or put it behind a reverse proxy. ufw alone is not protection.
• Skipping the “what breaks with two servers” question. Every “replace your whole stack” pitch glosses over this. Ask it before you’re mid-migration.
• Not registering the admin account immediately. Any fresh self-hosted install has a window where the setup page is reachable by anyone who finds the URL before you’ve claimed it. Register the moment the install script finishes, not “later tonight.”
• Confusing a tool’s general self-hosting reputation with its actual numbers. “Self-hosted” isn’t a resource tier. Two tools both described as lightweight can have wildly different real RAM/CPU needs. Read the specific tool’s own stated numbers, not the category’s reputation.

What This Doesn’t Do

One box only. The moment you need a second server, more traffic than one box handles, or you want redundancy, you’re back to manual provisioning each time. There’s no fleet management, no declarative multi-box config, no unified observability across machines. That’s a real trade-off, not a footnote.

Frequently Asked Questions

Is Temps really free?
Yes. The software itself has no license fee. You pay for the VPS it runs on, which is where the $5/mo comes from.

Does this replace Sentry’s exact feature set?
It accepts Sentry-compatible DSNs so your existing error-reporting code works unchanged, but it’s not a drop-in clone of every Sentry feature. Check your specific needs against what you actually use.

What if I outgrow one server?
You provision a second box manually, there’s no built-in fleet management. See “What This Doesn’t Do” above.

Is my admin console exposed to the internet by default?
Its control-plane binds to an address you configure (TEMPS_CONSOLE_ADMIN_ADDRESS), separate from the public traffic path. Register your admin account immediately after install regardless, the same advice that applies to any fresh self-hosted install.

Do I need to know Docker to run this?
Not really. The install script provisions Docker underneath for you. You’re not writing Docker Compose files or managing containers by hand day to day, the same way you wouldn’t on Vercel. It’s there, it’s just not something you touch directly for normal use.

Can I migrate an existing app over, or does it only work for new projects?
The install and the hosting side work the same either way, point an existing repo at it the same as a new one. What I haven’t personally tested is migrating historical error/analytics data out of Sentry or Plausible into Temps; treat that as a fresh start for monitoring data, not a data-import job.

The Real Number

$152/mo down to $5/mo is $1,824 a year back in your pocket, for four jobs that genuinely don’t need four separate companies billing you for them.

I put together a free one-page cheat sheet with the exact install command, the setup checklist, and the hardening steps. Grab it below if you want to run this yourself without re-reading this whole post.

Get the free $5/Mo Self-Hosted Cheat Sheet

Every command from this post, one page, as a PDF. Enter your email and we’ll send it straight to your inbox.

Get the Cheat Sheet →

If you want to see this whole setup walked through start to finish, I made a video covering the same build. [LINK: video URL, once the video ships].

The post Replace Vercel, Sentry & Plausible for $5/Month (Real Setup) appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Why did I create an AI chatbot for my website?

Users coming to my website come from different countries. Their arrival times vary depending on the countries they live in. So if I go to chat with them, I have to put my life under my website.

I wanted to overcome that barrier and provide instant responses to user queries, improving engagement and satisfaction.

It also allowed me to increase my website’s efficiency, automate repetitive tasks, and free up time for more complex issues. Plus it allowed me to increase conversions.

How would you like to be able to go to a website and get instant answers to your questions without waiting for someone to respond?

Basically, that is the main task an AI chatbot can do for your website!

Hence, AI chatbots are becoming a must for any website. That’s because it can accomplish tasks ranging from improving user experience to improving website efficiency and increasing conversions.

Here, I will introduce you to the steps to create a similar or more improved AI chatbot for your website. You can try using the click icon on the bottom right of this page.

By adding an AI chatbot to your website, you can:

Improving user experience

The biggest advantage of an AI chatbot is that it can give very accurate answers to user queries instantly. Imagine a user lands on your website in the middle of the night with a question. A chatbot can provide an immediate response instead of waiting for someone to get back to them. This will make your website more attractive and make your visitors happy.

Increasing efficiency

By automating repetitive tasks, an AI chatbot saves you time. Think about it. Instead of answering the same questions over and over again, you can do it through your chatbot. This allows you to focus on the more complex and important tasks of your website.

Increase conversions

AI chatbots can guide users through your website, helping them find what they’re looking for faster. This can lead to more sales, signups, or whatever else your website may be aiming for and have a positive impact.

In this guide, I’ll walk you through everything you need to know to build your own AI chatbot and integrate it into your WordPress site.

Understanding AI Chatbots: The Core Structure

Before we dive into the technical aspects, it is essential to understand the basic structure of an AI chatbot. It will be very useful for you while building or improving this chatbot.

Key components of an AI chatbot

User Interface (UI): The visual part through which users interact with the chatbot. This is shown in the image above.

Backend: Server-side logic that processes user input and generates responses.

AI Integration: The chatbot’s brain is powered by models like OpenAI.

Overview of how it works

Chatbots capture user input, send it to the backend, where AI processes it, and then displays the response to the user on the frontend.

Step-by-step guide to building your AI Chatbot

Now that you have a basic understanding of AI Chatbot, let’s start building your Chatbot.

I will guide you step by step. Follow these steps very carefully. I have used PHP, HTML, CSS, and JavaScript for this process. Don’t worry I’m not an expert in these things like you. But you can make this process very easy by using ChatGPT or Claude as a support.

However, I am providing all the codes you need here.

AI Chatbot For WordPress

Creating a Chatbot UI

First impressions are the foundation of anything. A good-looking chatbot makes a big difference to your website. Here’s how to design a simple yet attractive chatbot interface.

Essential UI elements

Chat Box: This is where the conversation happens. It shows the chat history between the user and the chatbot.

Input Field: Allows users to type their messages here.

Send Button: This is used to send the message to the chatbot.

To create this UI, you will use HTML and CSS. You can download all related files below.

After entering the AI-chatbot folder, you can see two folders: front and back. Go inside the front folder. There are 4 files as shown below.

Here the chatbot.html file contains everything. But the Index.html, script.js, and style.css files contain only the related things. From there you can use these files appropriately.

Either way, open chatbot.html or Index.html in your browser. Then you will see the chatbot as below.

But you still can’t chat with this.

Set up Chatbot code in the backend

Now that your UI is ready, it’s time to access the code that will make your chatbot work.

1. Install and activate WPCode Lite.

2. Paste the code in the back folder here. Note, the Code Type should be changed to PHP Snippet.
3. Connecting the OpenAI API Key.
   Register on the OpenAI website and get an OpenAI API key. Because our chatbot is powered by the OpenAI API.  Keep this confidential. Next, enter the OpenAI API key in the snippet and save the snippet.

Linking the UI with the backend

Now that your front and back panels are ready, it’s time to connect them together. This is where JavaScript comes into play.

Now open the script.js file in the front folder. You can use Notepad for this. Go there and update your domain name and save the file.

Eg: replace https://YourWebsite.com with your site domain name.

If you did everything correctly, now you just have to open the index.html file again. To your surprise, your chatbot will work like the image below.

Advanced Customisation: Taking Your Chatbot to the Next Level

This chatbot is designed to suit my site. That is, only matters related to WordPress can be chatted through this chat button. When asked about a matter not related to WordPress, it replies, “I am trained to assist with WordPress-related questions. Feel free to ask me anything about WordPress”.

So, how to customise this chatbot for you?

System Prompt Customisation

Customising your AI chatbot’s system prompt is essential to ensure it aligns with the specific needs of your website and the type of interaction you want to have with your users. So here’s how to adjust your system prompt to suit different websites:

1. Understand the purpose of your website

Identify the primary function of your website. Is it an e-commerce site, a blog, a tech support platform or a content-driven site? Your chatbot’s system prompt should reflect the primary purpose and type of queries users might have.

2. Define the scope of the interaction

Clearly state the purpose for which your chatbot is designed. For example, if your website focuses on e-commerce, chatbots can assist with product inquiries, order tracking, or product recommendations. The scope should be narrow enough to keep the chatbot focused but broad enough to handle common user needs.

3. Crafting the System Prompt

Change the language and focus of the system prompt based on the context of the site. Here’s how you can adjust the provided trigger for different types of websites:

Example 1: E-commerce Website:

You are a knowledgeable shopping assistant on our online store. Your task is to help users find products, answer questions about orders, provide product recommendations, and assist with any inquiries related to our store. Engage users in friendly conversations to enhance their shopping experience. Do not respond to questions unrelated to shopping or our products. If asked, politely state that you are here to assist with shopping-related queries.

Example 2: Tech Support Website

You are a tech support specialist. Your task is to help users troubleshoot technical issues, provide guidance on software and hardware products, and assist with inquiries related to our tech support services. Engage users in problem-solving conversations to resolve their technical problems. Do not respond to questions outside of tech support. If asked, politely inform them that you specialize in providing tech support assistance.

Example 3: Blog or Content-Focused Website

You are an expert content guide for our website. Your task is to help users find articles, explain content topics, suggest related posts, and assist with any questions about our blog content. Engage users in informative conversations to enrich their reading experience. Do not respond to questions unrelated to our content. If asked, gently redirect them to the relevant blog topics.

Example 4: Educational Platform

You are an educational assistant for our online learning platform. Your task is to help users navigate courses, answer questions about course content, provide study tips, and assist with any inquiries related to learning on our platform. Engage users in supportive conversations to enhance their learning journey. Do not respond to questions outside of education-related topics. If asked, kindly direct them to the appropriate course material.

4. Enter the brand identity

Make sure the tone and style of the prompt aligns with your brand’s voice. If your brand is casual and fun, the query should reflect that. For a more professional brand, use formal and precise language.

5. Test and Iterate

After customizing your system prompt, test it with real user interactions to see if it meets the intended objectives. Gather feedback and make adjustments as needed to fine-tune the chatbot’s performance.

By customizing your chatbot’s system prompts, you can ensure that it provides relevant, useful and on-brand responses, making your website’s user experience more engaging and effective.

After you prepare your prompt, go to “Add the last prompt to the conversation history” in the Backend Snippet and enter the prompt you prepared.

Then save the code snippet. Depending on the success of your prompting, the output of your chatbot will be successful.

Icon Customization

But your chatbot still has the same icon as my chatbot. Let’s change that too.

Go to “load_chat_bot_base_configuration” and change your user_avatar_url and bot_image_url to the icon you require.

Other minor changes

You can change the Startup Message to suit you. You can also change the font size and commonButtons of your chatbot.

Final Steps: Publishing Your Chatbot on WordPress

Now you can integrate your chatbot into your WordPress website pages.
For that, we are again asking for help in the code snippet.

Go to Header and Footer in the code snippet. Go there and paste the full code, HTML, CSS, and JavaScript, in the footer.

Bonus Tip: If you run into any WordPress errors while setting up your chatbot, don’t worry. My WP Error Expert AI tool can help you fix many errors easily. And if you’re a web developer, check out my other AI tools designed to make your life easier.

Conclusion

In conclusion, integrating an AI chatbot into your WordPress site can significantly enhance user experience, increase efficiency, and drive conversions.

By automating responses to common queries, an AI chatbot ensures that visitors receive instant support, no matter the time of day.

This guide provides a comprehensive, step-by-step process to build and customize an AI chatbot that aligns with your website’s specific needs, whether it’s for e-commerce, tech support, content guidance, or education.

By following these steps, you can create a chatbot that improves customer satisfaction and optimizes your website’s performance, ultimately leading to better engagement and outcomes.

AI Chatbot For WordPress

The post How to Build and Integrate an AI Chatbot into Your WordPress Site: A Complete Guide appeared first on The Beginner’s Playbook for Fixing WordPress Errors.