The post I Built a Fake Home Theater… appeared first on WEBNET Hosting.

The post Creators Give One Word Take To Our New Screwdriver appeared first on WEBNET Hosting.

Summarize with:

Follow:

Buy multiple domain extensions when you need to protect an established brand from squatters, reach customers in specific countries, or cover misspellings and lookalike addresses that could send customers elsewhere. One domain is usually enough when none of these risks applies.

Registering multiple domain names doesn’t improve SEO on its own, so redirect extra domains to your primary website instead of publishing duplicate copies of it.

The right portfolio follows a priority order: primary extension first, then the country-code domain of your main market, then one or two recognized alternatives. If you do need extras, one to three is almost always enough.

Hostinger’s Brand protection page lists every available variation of a name you own and registers the selected ones in a single checkout, so protecting a brand across extensions takes minutes.

When is it recommended to buy multiple domain extensions?

Buying multiple domain extensions is worth it in four situations: protecting your brand identity, targeting customers in specific countries, capturing common misspellings, and preventing customer confusion. Each one removes a concrete risk; when none of them applies, the money is better spent elsewhere.

Brand protection, misspellings, and customer confusion all follow the same logic. Domain registration is first-come, first-served.

Every extension is a separate registration of the same name under a different top-level domain (TLD), a core part ofhow top-level domains work. If you own domain.com, whoever registers domain.net first owns it – whether that’s you, a competitor, or a squatter.

To protect your brand from squatters

Owning the obvious variations of your brand name costs less than recovering them from a stranger. Squatters register versions of known names to resell them at a markup or to trade on their reputation. The most reliable way toprotect your brand from domain squatting is to hold those versions yourself before anyone else does.

A defensive registration runs $10–30 per year. Recovering a name someone else registered means filing a complaint under the Uniform Domain-Name Dispute-Resolution Policy (UDRP). That starts at $1,500 in World Intellectual Property Organization fees alone, before lawyers – and the panel’s decision isn’t guaranteed to go your way. Ten years of renewals cost less than one dispute.

To target customers in specific countries

A country-code top-level domain (ccTLD), like .de, .co.uk, or .com.br, tells local customers they’re buying from someone who operates in their market. Local extensions carry weight where it matters commercially: shoppers are more willing to enter payment details, and local partners read them as a commitment.

Register the ccTLD when you already have customers, local pricing, or fulfillment in that country. Skip it while expansion is still only a plan.

To capture common misspellings

Misspelled versions of your domain send real visitors to whoever owns them. It happens even at the extension level. Someone intending to visit domain.com might type domain.co instead, which is one reason .co can be useful in a defensive domain portfolio.

Name-level typos follow the same logic at a larger scale. Popular brands see misspellings of their name searched hundreds of times a month, and a typo domain in the wrong hands collects that traffic or, worse, imitates the real site. You don’t need to buy all the possible misspellings of your brand, only the one or two that people usually make.

To prevent customer confusion

Customers who guess your address should reach you, not whoever owns the extension they guessed. A competitor who owns the .net domain of your name collects your walk-in traffic, and a lookalike domain in a stranger’s hands provides a ready-made address for phishing emails that impersonate your business.

Paid campaigns, printed materials, and word of mouth all produce visitors who type addresses from memory. Every mistyped guess that sends customers to someone else is a customer you paid to lose.

When is one domain extension enough?

One domain extension is enough when your brand has no traffic worth protecting, your audience is local, and your name is too generic for a squatter to profit from. Squatters target names people already search for, so a new project with no established audience is generally a lower-priority target.

A squatter who registers bestplumbingservices.net can’t resell it to you at a markup, because you could choose from dozens of similar domain names. The risk that justifies a defensive portfolio – someone holding your specific name hostage – doesn’t apply when there are plenty of similar domain names available.

The renewal cost also argues against unnecessary registrations. Five extra domains at $15–30 each cost $75–150 per year, and that figure compounds at renewal, not the first-year promotions registrars advertise.Domain registration and renewal costs vary widely by extension, so a defensive portfolio that looks affordable at registration can look different a year later.

Register extras when the brand earns enough traffic that someone else holding a variation would cost you something real. Before that, the money is better spent on the site itself.

Which domain extensions should you prioritize?

Prioritize domain extensions in this order: your primary extension first, the ccTLD of your main market second, one or two widely recognized alternatives third, and typo variations last. The order follows risk, not price.

Choosing the right primary domain name comes before any defensive buying. Every variation you register inherits whatever name you settle on, so a name that’s easy to mistype means more variations to defend..

Here’s how each type maps to who needs it and when to skip it:

If your preferred primary domain is already registered by someone else, the recognized alternatives in the table are the first place to look – a full breakdown ofalternative extensions when your preferred domain is taken can help narrow the choice.

How many domain extensions do most businesses need?

Most businesses need one primary domain, plus one to three extra extensions. A local business does fine with the primary alone; a national brand adds one or two recognized alternatives, and an international one adds the ccTLD of each market it operates in.

Every registration past the first should have a reason you can name. If you can’t say which risk a domain removes, skip it.

Do multiple domain extensions help SEO?

Multiple domain extensions don’t help SEO on their own. Search engines rank websites and their content, not registration lists, so a domain showing a placeholder page contributes nothing to the site you actually run. Redirecting a freshly registered extension adds nothing either, because a domain nobody has ever linked to has no ranking signals to pass on.

The damage shows up when owners publish on every extension they own: identical sites compete with each other, and search engines pick one version to rank while filtering out the rest.

Country domains are the one partial exception. A ccTLD works as a strong geographic signal, but the benefit arrives with genuinely localized content, such as local language, local currency, and a local address. A .de that redirects to your .com sends no geographic signal at all; it just catches the customers who typed it.

What should you do with your extra domain extensions?

Redirect them. Multiple domains pointing to one website is the point of a defensive portfolio, and a permanent 301 redirect is the mechanism: it forwards visitors and tells search engines which address is the real one.

The steps toredirect additional domains to your main website take minutes per domain with most registrars.

A working portfolio needs four things in place:

1. One primary domain. Content, backlinks, business cards, and ad campaigns all use this single address.
2. A 301 redirect from every extra extension to it. A 302 signals a temporary move, so search engines treat it differently.
3. Valid SSL certificates on the redirected domains. Browsers verify the certificate before following the redirect, so an expired one displays a security warning instead of your homepage.
4. Auto-renewal on every defensive registration. An expired defensive domain returns to the open market, which undoes the point of buying it.

Redirecting also gets confused with transferring, and they solve different problems. Thedifference between redirecting and transferring a domain comes down to what moves: a transfer changes which registrar manages the name, while a redirect changes where visitors end up.

Consolidating a scattered portfolio usually means doing both: transfers to bring every domain under one roof and redirects to point them all to the same website.

How to protect your brand across multiple extensions with Hostinger

Open the Brand protection page in hPanel, select the extensions you want, and register them all in one checkout. The page lists every version of your name with its price, marks the ones you already own with an Owned label, and suggests a ready-made bundle of the most common defensive picks.

Hostinger supports more than 500 extensions, so the page loads every variation of your name at once instead of making youcheck domain availability one at a time. You act on the handful that matter.

Brand protection works on domains already in your Hostinger account. If you’re starting from scratch,buying and registering a domain first takes a few minutes, and once it’s in your account, Brand protection shows every available variation of it.

To secure several variations at once:

1. In hPanel, go to Domains and click Manage next to the desired domain.
2. Select Brand protection in the left sidebar.
3. Click Add to cart on the variations you want, or add the suggested bundle.
4. Click Continue to cart, set the registration term for each domain, and complete the checkout in one payment.

Your contact details apply across the whole cart, and any extension that requires additional information, as some country codes do, gets flagged before payment. Free WHOIS privacy protection is included with each registration, and the cart shows every domain’s renewal rate and renewal date before you commit.

After checkout, each new domain appears in the Domain portfolio with its own Auto-renewal toggle.

How to decide if buying another domain extension is worth it

Another domain extension is worth buying when it protects your brand, supports the market you serve, or costs little relative to the risk it mitigates. Three questions help you check:

• Would a stranger owning this variation cost you customers, revenue, or reputation?
• Do you serve the country behind that ccTLD today?
• Is the renewal price trivial next to the risk it removes?

Register the extension when you can answer yes to the first or second question, and yes to the third. Anything else is a maybe, and maybes belong on a watchlist, not in a cart.

Review the list at renewal time, with the real yearly cost on screen, rather than buying in advance for markets and threats that may never arrive. New extensions launch every year, so this isn’t a decision you make only once.

The brands that handle it well treat their domain list like the rest of their infrastructure: small, current, and tied to a purpose they can name.

All of the tutorial content on this website is subject to

Hostinger’s rigorous editorial standards and values.

The author

Bruno Santana

Bruno is a Content Writer at Hostinger, focused on creating and optimizing helpful, engaging articles about web development and marketing. With a background in journalism, he combines storytelling with practical insights to make complex topics easier to understand. He has also contributed to publications like MacMagazine and Jornal A Tarde. Outside of work, Bruno enjoys exploring art, cooking, and technology.

The post Should you buy multiple domain extensions? appeared first on WEBNET Hosting.

Summarize with:

Follow:

The best Manus alternatives in 2026 fall into three groups: ready-to-use general agents like ChatGPT, specialized business and research tools like Hostinger Agent and Genspark, and open-source options like OpenManus and n8n that you run on your own server.

Each group answers a different Manus limitation: Manus runs every task on its own infrastructure and bills per task in credits rather than a flat rate.

Hosted alternatives solve the pricing problem – you can start in minutes and pay a flat monthly fee. Self-hosted alternatives are free to use and keep your data on your own server, but you handle setup and maintenance yourself. Predictable costs, data control, and your technical skills decide which one fits best.

Best Manus AI alternatives at a glance

The best Manus alternatives cover business operations, research, workflow automation, and software engineering, with starting prices from free to $42.50 per month.

1. Hostinger Agent: role-based agents with guided skills

• Best for: Solopreneurs and small business owners who need specialized agents for SEO, content, marketing, legal, and sales.
• Price: From $6.99/month.
• Open source: No.

Hostinger Agent is Hostinger’s AI assistant for small business owners who manage content, SEO, marketing, legal, and sales without a dedicated team.

It covers the business work that Manus users delegate to a general agent, split across seven domain specialists rather than one assistant you have to prompt and guide. The lineup includes Business Advisor, Creative Writer, SEO Consultant, Marketing Planner, Legal Advisor, Customer Communications, and Sales & Outreach.

Business context carries forward between conversations, so agents already know your brand, preferences, and past decisions each time.

Hostinger Agent key features

• Seven specialized agents. Strategy, writing, SEO, marketing, legal, customer communications, and sales, each with its own skill set rather than one shared prompt.
• 150+ guided skills. SEO audits covering 24 on-page factors, blog posts, logo design, content calendars, pricing reviews, privacy policy drafts, and lead outreach.
• 1,000+ app connections. Acts through Gmail, Slack, WhatsApp, HubSpot, Notion, Jira, GitHub, and Figma without leaving the chat.
• Persistent business memory. Agents keep your brand, preferences, and past decisions across conversations.
• Scheduled recurring tasks. Image and logo generation and file uploads with version tracking.

Hostinger Agent limitations

• No autonomous execution. No independent web browsing, code execution, or sandboxed environment.
• Skill-bounded scope. Requests outside the 150+ built-in workflows lose the guided structure.
• Cloud-hosted only. No self-hosted option, which OpenClaw and OpenManus cover.

Hostinger Agent pricing:

Hostinger Agent starts at $6.99/month on the 12-month plan and renews at $8.99/month, so it is worth factoring that in before committing. Shorter-term plans are available at higher monthly rates for those who prefer more flexibility.

All plans include 1,000 credits per month, refreshing automatically with no manual top-ups needed. Credits cover the full range of tasks across all seven agents: skill runs, image generation, scheduled automations, and file handling. A 30-day money-back guarantee applies to all plans.

2. ChatGPT: general-purpose assistant with built-in browsing

• Best for: Individuals who want a ready-made agent for everyday tasks and browser actions; teams that want persistent Workspace agents.
• Price: Free; individual plans from $8/month; Business from $20/user/month billed annually (minimum 2 seats).
• Open source: No.

ChatGPT is OpenAI’s general-purpose AI agent with built-in browsing, scheduled tasks, and app connections on individual plans, and a separate Workspace agents product for business teams.

For Manus users considering it as a replacement, its agent capabilities are split across two plan types – individual and Business – and only Business includes Workspace agents.

On individual plans (Go, Plus, and Pro), ChatGPT includes a built-in browser on every tier, scheduled tasks from the Go plan upward, and app connections to internal tools on Plus and above. These cover everyday research, automations, and integrations without needing a team account.

Workspace agents require a Business plan with a minimum of two seats. The full product includes a persistent template gallery, an org-wide agent directory, and 24/7 scheduled runs. For solo Manus users, this is the key constraint: the feature that most directly replaces Manus is not available on any individual plan, including Pro from $100/month.

ChatGPT key features

• Model access. GPT-5.6 Sol on Plus, GPT-5.6 Sol Pro on Pro, all frontier models on Business.
• Template gallery and org directory. Workspace agents are shared across the company rather than rebuilt per person.
• 24/7 scheduled runs. Business-tier agents work on a cadence without prompting.

ChatGPT limitations

• Usage limits on every individual plan. Message and feature caps vary by tier and are not always published as fixed numbers.
• Ads on Free and Go. Sponsored placements appear below responses.
• No self-hosted option. Everything runs on OpenAI’s infrastructure, the same constraint that pushes people off Manus.

ChatGPT pricing:

Individual plans run from $0/month (Free) to $8/month (Go), $20/month (Plus), and from $100/month (Pro). Workspace agents require a Business plan at $20/user/month billed annually or $25/user/month on a monthly plan, with a minimum of two seats. Enterprise pricing is custom.

3. Genspark: Super Agent and AI Slides

• Best for: Research-heavy tasks, presentations, and multi-modal content that benefits from parallel AI agents.
• Price: Free (100 credits/day); paid plans from $19.99/month billed annually.
• Open source: No.

Genspark, currently on AI Workspace 6.0, is an AI workspace built around Super Agent and AI Slides, developed for research-heavy work, content creation in text, images, and video, and AI presentations. Super Agent handles complex research tasks autonomously, while GenTeam coordinates multiple AI agents working in parallel.

AI Slides and Deep Research make it the strongest match for readers who use Manus mainly for research and presentations. Super Agent researches the topic first, then builds the output, following the same research-before-execution pattern Manus uses.

The free tier gives 100 credits per day, and agent tasks run on it. Standard requests cost 30 to 150 credits each; Ultra mode, which uses the most capable models, costs 100 to 600 credits per request. A single Ultra task can consume the full daily free allowance.

Genspark key features

• Model choice. Access to multiple major model providers from one workspace.
• Saved workflows. Rerun a research or content process without rebuilding it.
• Commercial content license. Included on paid plans, so generated material is usable in client work.

Genspark limitations

• No public pricing page. Plan details are visible only after you create an account.
• Credits do not carry over. Monthly allocations reset each billing cycle.
• Fair-use throttle. Heavy chat or image use triggers a five-hour cooldown that buying credits will not lift.

Genspark pricing:

Genspark’s free plan gives 100 credits per day, The Plus plan starts at $19.99/month billed annually and includes 10,000 credits per month, 50 GB of storage, unlimited AI Chat and image generation, and a commercial content license.

The Pro plan at $199.99/month raises that to 125,000 credits and 1 TB of storage. Genspark states that the unlimited chat and image perks are guaranteed through December 31, 2026.

4. Lindy: Slack-native AI teammate

• Best for: Teams that want a persistent AI teammate in Slack handling recurring workflows, meetings, and inbox management.
• Price: From $29.99/user/month; 7-day free trial.
• Open source: No.

Lindy is an AI teammate designed to live inside your team’s Slack workspace and handle recurring work, such as inbox management, meeting notes, daily briefs, and scheduled follow-ups. You give it a task, and it does the work.

The credit system maps to the scope of each task. Everyday lookups and replies cost 2 to 250 credits; research tasks and longer reports run 250 to 1,000 credits. Complex dashboard builds and heavy scheduled workflows reach 1,000 to 2,500 credits – close to a full month’s allowance for one seat. Credits pool across the whole team, which means one person’s heavy use draws from everyone’s shared balance.

Lindy also supports computer use, meaning it can operate software directly rather than only connecting through APIs. Combined with MCP support and over 1,000 integrations, it covers most of the recurring operational work Manus users hand off to an agent.

Lindy key features

• Meeting support. Joins calls as a named participant, records, transcribes, and files recordings in shared folders.
• No surprise bills. Lindy pauses and notifies admins when the credit pool runs low, and per-seat caps are configurable.
• 40+ built-in skills. Research, data analysis, decks, and dashboards, plus custom skills your team builds once and reuses.

Lindy limitations

• Slack-centric by design. Teams working elsewhere lose most of the product.
• Per-seat pricing. Costs grow with headcount from the $29.99/user/month base.
• No free tier. Access needs a paid seat once the seven-day trial ends, and direct signups are billed immediately.
• Approval gates. Actions with external consequences stall until a named approver signs off, slowing unattended workflows.

Lindy pricing:

Lindy starts at $29.99/user/month, which includes 3,000 credits per user per month, pooled across the workspace. Higher tiers add more credits and connected inboxes. Enterprise adds HIPAA compliance for healthcare data, company-account login, automatic user syncing, and activity logs.

Credits can be topped up at $10 per 1,000 at any time. The 7-day trial starts automatically when anyone in your Slack first tags Lindy.

5. OpenManus: open-source Manus replication

• Best for: Developers and technical users who want a self-hosted, open-source Manus-style agent with bring-your-own-model flexibility.
• Price: Free (self-hosted; bring your own API keys).
• Open source: Yes (MIT).

OpenManus is an open-source AI agent framework built by researchers from the MetaGPT team as a rebuild of Manus without the credit system. It is one of the earliest and most referenced open-source alternatives in this space, with 58,100+ GitHub stars.

It runs on your machine with your own model API keys and handles the same categories of tasks Manus does: browser automation, file operations, and multi-step agent runs.

Setup requires cloning the repository, adding your model credentials to a config.toml file, and running python main.py. A recent main-branch update integrates Browser Use CLI 3.0, which attaches to a local Chrome session for browser automation without an additional API key.

Two caveats are worth noting before you start: the multi-agent flow is labeled “unstable” in the project’s README, and the latest tagged release, v0.3.0, dates back to April 2025, even though the main branch receives regular commits.

OpenManus key features

• DataAnalysis agent. Optional add-on for data analysis and visualization tasks.
• Local browser mode. Attaches to your existing Chrome session, so browser automation needs no extra API key.
• 59 contributors. Built and maintained by researchers from the MetaGPT team.

OpenManus limitations

• Technical setup required. Python 3.12, dependency installation, and manual configuration, with no graphical interface.
• No managed hosting. You run the infrastructure, cover model API costs, and handle updates.

OpenManus pricing:

OpenManus is free to download and self-host under the MIT license. Running it costs whatever your model provider charges per API call; there is no platform subscription or usage fee.

6. AutoGPT: agent platform with a visual builder

• Best for: Users who want to build and run autonomous agents on a schedule, either in the cloud or self-hosted, with visual workflow control.
• Price: Free (self-hosted); cloud from $42.50/month billed annually.
• Open source: Partially (classic agent is MIT; cloud Platform uses Polyform Shield).

AutoGPT is a platform for building and running autonomous AI agents. It replaces the open-ended runs Manus handles on demand with agents you define once and rerun on a schedule.

The product has four parts. AutoPilot turns a plain-language description into a working agent; Agents is the dashboard for monitoring runs and costs; Marketplace offers ready-made agents you can deploy in one click; and Build is a visual block editor for step-by-step control.

You can run it two ways. The hosted Platform is managed by AutoGPT, requires no model API keys, and uses Polyform Shield, which permits personal and internal business use but prohibits building a competing hosted service on top of it. The classic standalone agent, in the classic/ folder, is MIT-licensed and runs anywhere, on your own infrastructure with your own model keys.

Agent runs on the Platform are pay-as-you-go from a prepaid balance. Your subscription covers AutoPilot chat, while the balance covers whatever your agents consume when they run.

AutoGPT key features

• Browser automation on all plans. Agents browse, scrape, and interact with pages.
• 45+ integrations. Gmail, Google Calendar, GitHub, Slack, HubSpot, Notion, Linear, and Airtable.
• Schedule and trigger support. Run agents on demand, on a schedule, or from a webhook.
• Per-task spending caps. Set a budget per task and watch costs as they accrue.
• Approval steps. Agents pause and ask before taking consequential actions.

AutoGPT limitations

• No free cloud tier. The managed platform needs a paid plan, and self-hosting requires Docker plus your own model keys.
• Platform is in beta. The current release still carries a beta version tag.

AutoGPT pricing:

The self-hosted path is free, with no license fee; you cover infrastructure and model API costs. The cloud Platform starts at $42.50/month, billed annually, for Pro, and at $272/month for Max, which includes 8.5 times Pro’s chat allowance.

The subscription covers AutoPilot chat. The agent runs the bill separately from a prepaid balance and is priced the same on every plan, so a higher tier buys more chat rather than cheaper automation.

7. CrewAI: Python framework for agent crews

• Best for: Developers building production-ready multi-agent systems where different agents have distinct roles and collaborate on complex tasks.
• Price: Free (50 executions/month on CrewAI AMP); enterprise pricing on request.
• Open source: Yes (MIT).

CrewAI is an open-source Python framework for building and coordinatingmulti-agent systems: networks of specialized AI agents that collaborate on complex tasks, each with a defined role, goal, and set of tools. It replaces Manus’ multi-step task handling with agent roles you define in code.

With roughly 29 million monthly downloads from PyPI, Python’s package registry,, it ranks among the most widely usedAI agent builders in the Python ecosystem.

The framework has two core concepts that work together. Crews are autonomous, role-based agent teams built for tasks that benefit from collaborative decision-making, in which agents hand off work to each other as needed. Flows are event-driven workflows that give precise control over the order in which steps run, what data is carried between them, and how the system behaves in production.

Most real-world implementations combine both: Crews for the reasoning, Flows for the structure.

CrewAI AMP Suite is the commercial layer built on top of the framework. It adds a visual Studio editor, runs your agents on CrewAI’s servers with a live view of each step, and lets a person approve consequential actions before they happen. The free tier includes 50 workflow executions per month on CrewAI’s cloud.

CrewAI key features

• Exportable to Python. The visual Studio editor produces code you own rather than a locked configuration.
• Real-time tracing. Every model call, tool call, and memory read is visible while it runs.
• Enterprise controls. SSO, role-based access, PII redaction, and VPC or on-premise deployment.

CrewAI limitations

• Python-first. Building crews takes code, and the Studio editor only covers the simpler configurations.
• Learning curve. Crews and Flows are separate patterns that take time to combine well.

CrewAI pricing:

The open-source framework is free with no restrictions. CrewAI AMP’s Basic plan is also free and includes access to the Studio editor, GitHub integration, and 50 workflow executions per month in CrewAI’s cloud.

Enterprise pricing requires contacting the team and includes a company account login, role-based permissions, automatic removal of personal data, deployment on your own infrastructure, US federal security certification, and a 45-day onboarding program.

8. OpenClaw: local agent inside your chat apps

• Best for: Users who want a private, self-hosted personal agent that runs on their own machine and connects to the chat apps they already use.
• Price: Free (MIT, self-hosted); managed hosting from $7.99/month (annual billing).
• Open source: Yes (MIT).

OpenClaw is an open-source personal AI agent that runs locally on your machine and connects to the messaging apps you already use, including WhatsApp, Telegram, Slack, Discord, iMessage, Signal, and Google Chat.

You set up OpenClaw with a one-line installer, npm, or Docker, then point it at your model provider. It handles the same personal assistant work Manus does, including email, calendar, files, browser sessions, and shell commands, with persistent memory across every conversation. All your data, credentials, and agent state stay on your own infrastructure.

The project has 387,400+ GitHub stars and 2,940 contributors. It is developed under the OpenClaw Foundation, a non-profit organization.

You can sign in with a ChatGPT Plus or Pro subscription instead of a pay-per-token API key, which removes the variable API cost that most self-hosted agent setups carry.

Hostinger runs OpenClaw as a managed service through itsAI automation apps, handling installation, updates, and infrastructure so you keep the privacy benefits of a self-hosted agent without the ongoing upkeep.

OpenClaw key features

• 29 chat channels. WhatsApp, Telegram, Slack, Discord, iMessage, Signal, and Google Chat among them.
• Skills and plugins. Community extensions through ClawHub, and agents can write and install their own.
• Optional sandboxing. Tools run with full host access unless you configure a sandbox.

OpenClaw limitations

• Technical setup required. Connecting model providers, channels, and permissions takes time beyond the install.
• You manage the infrastructure. Updates, uptime, and backups are yours on a self-hosted install.
• Fast-moving project. The release pace has introduced instability, so production installs should track the stable channel.

OpenClaw pricing:

OpenClaw is free to self-host under the MIT license. Your costs depend on which model provider you connect to and how much you use it. A ChatGPT Plus or Pro subscription works as the model source, replacing per-token billing.

Hostinger’s managed setup starts at $7.99/month (annual billing), and it handles the infrastructure for users who want a private agent without the upkeep.

9. n8n: workflow automation with AI nodes

• Best for: Technical teams who want to build structured AI workflows they can inspect, version, and control, without per-seat pricing.
• Price: Free (Community Edition, self-hosted); cloud from $20/month billed annually.
• Open source: No (fair-code; free to self-host under the Sustainable Use License).

n8n is a workflow automation platform that combines a visual node editor, AI capabilities, and flexible self-hosting. It sits at the intersection ofAI agents and automation: not an autonomous agent that makes its own decisions, but a programmable system where you design the process and AI handles the steps you assign it.

The platform supportsagentic workflows, retrieval from your own documents (RAG), and connections to outside tools through MCP, with every reasoning step visible on the canvas.. You build in the UI, drop into JavaScript or Python when needed, and replay individual steps without re-running the whole workflow. Testing against real data before you deploy is built in.

It replaces the Manus tasks you run repeatedly, trading autonomous decisions for a process you define once. The pricing model reflects that: you pay per complete workflow execution, regardless of how many nodes the workflow contains.

The Starter cloud plan includes unlimited users, making n8n competitive for teams that run into per-seat costs elsewhere. Self-hosting removes per-seat cost entirely, and managed n8n hosting covers the Docker setup, updates, and backups.

n8n key features

• 400+ integrations. Native nodes for common apps, plus HTTP request nodes for anything without one.
• Step-level replay. Rerun a single step instead of the whole workflow while debugging.
• Git-based version control. Available from the Business tier, alongside environments and audit logging.

n8n limitations

• Fair-code license. Internal business use is allowed, but this is not an OSI-approved license and reselling n8n as a hosted service is restricted.
• AI Assistant is in preview. The built-in workflow-building assistant is still marked preview on cloud plans.

n8n pricing:

The Community Edition is free to self-host with no user limit, no execution caps, and no license fee. Cloud plans start at $20/month billed annually (Starter: 2,500 workflow executions per month, unlimited users, 2,300 AI credits).

The Pro plan at $50/month raises the execution limit to 10,000 and adds workflow history, execution search, and admin roles. Business and Enterprise tiers add Git-based version control, environments, SSO, and audit logging.

10. Devin: AI software engineer

• Best for: Software engineering teams that want an autonomous agent for coding, code review, testing, incident triage, and codebase documentation.
• Price: Free ($0, light quota); Pro $20/month; Max $200/month.
• Open source: No.

Devin is an AI software engineer built by Cognition AI. It handles the coding work that typically requires a human developer: writing and reviewing code, fixing bugs, triaging incidents, and shipping pull requests.

It replaces the coding work Manus handles, and it is built specifically for engineering teams rather than general-purpose use.

The platform has four parts: Devin Cloud for autonomous agent runs in a managed environment; Devin Desktop for inline completions and edits in your code editor; Devin CLI for running Devin from the terminal; and Devin Review for automated pull request review and visual checks on the interface.

DeepWiki, Cognition’s companion codebase documentation tool, auto-generates documentation and system diagrams for existing codebases. Fleet mode lets you run agents in parallel across large migrations and multi-repo projects.

For the open-source equivalent, OpenHands (formerly OpenDevin) covers similar ground under a permissive license, and is worth exploring if self-hosting matters more than the managed experience.

Devin key features

• Full development environment. Browser, terminal, code editor, and test runner, with Devin responding to failed builds and review comments on its own.
• Playbooks. Reusable procedure files that tell Devin how your team handles a task, so the same steps repeat across sessions instead of being re-explained each time.
• Integrations. GitHub, GitLab, Bitbucket, Slack, Teams, Linear, and Jira on Pro and above.

Devin limitations

• Free tier cannot run cloud agents. It covers a light quota and a restricted model set, with Devin Cloud starting at Pro.
• Concurrent session cap. Pro and Max allow 10 at once, and unlimited sessions require the Team plan.
• Team pricing is additive. $80/month base plus $40/month per developer seat.

Devin pricing:

The free plan includes a light agent quota, unlimited inline edits, and unlimited Tab completions, which covers testing and occasional use. Pro costs $20/month and adds access to the latest models, Devin Cloud agents, and up to 10 concurrent sessions. Max costs $200/month, and raises every usage allowance, with the same 10 concurrent session cap.

Teams start at $80/month plus $40/month per full developer seat, with unlimited team members and concurrent sessions. Usage allowances refresh daily and weekly; cost per session varies by model and task complexity.

Why look for a Manus alternative?

Three characteristics separate Manus from most alternatives here: credit-based pricing, cloud-only execution, and an ownership structure that reversed in April 2026.

Pro starts at $20/month for 4,000 monthly credits, and the next tier costs $40/month for 8,000, both with 20 concurrent tasks. The rate per credit is the same either way, so upgrading buys volume, not a better price.

The free plan runs only Manus 1.6 Lite in Agent Mode, with 300 credits refreshing daily and one concurrent task. The daily allowance looks generous, but Manus scopes those credits to “quickly answering simple questions,” and they don’t accumulate, so real agent work still needs a paid tier.

Meta closed its roughly $2 billion acquisition of Manus on December 29, 2025. According to TechCrunch, China’s National Development and Reform Commission ordered both parties to withdraw the transaction on April 27, 2026.

Manus announced its return to independent operations on August 11, 2026. Accounts in some jurisdictions had data created on or after December 29, 2025, deleted on August 23 and 24, with a backup window that closed the morning of August 23.

For anyone relying on the platform for ongoing or sensitive work, that kind of disruption is hard to plan around.

Which Manus alternative should you choose?

The right pick depends on what you were actually using Manus for.

For general autonomous tasks: ChatGPT. Built-in browsing and scheduled tasks on individual plans from $8/month, with no credit system to track. AutoGPT if you want the same open-ended runs on your own infrastructure.

For research and presentations: Genspark. Includes a free tier included, Super Agent follows the same research-before-execution pattern as Manus, and AI Slides covers the deck use case directly.

For business operations: Hostinger Agent. Guided specialists for content, SEO, marketing, legal, and sales, for less than Manus’ cheapest paid plan.

For software engineering: Devin. Purpose-built for the full development lifecycle: code review, incident triage, and PR shipping. Free plan available.

For team workflows on a schedule: Lindy, if your team is in Slack and you want an AI that acts like a colleague; n8n if you need to define every step and inspect every run. Both let you cap spend before a run.

For privacy and control over your own machine: OpenClaw. The most active self-hosted option, with one of the largest open-source contributor communities. Managed hosting is available through Hostinger if you want the privacy benefits without maintaining a server.

For building at the framework level: OpenManus for a standalone self-hosted agent; CrewAI if you need to orchestrate multiple specialized agents in production code.

If your main Manus use case was building web or mobile apps, that’s a different category: anAI website builder will serve you better than any agent here.

Spending caps and approval gates were niche features a year ago. Lindy, AutoGPT, and n8n now ship them by default, and that is the first thing to check on whatever you pick.

All of the tutorial content on this website is subject to

Hostinger’s rigorous editorial standards and values.

The author

Bruno Santana

Bruno is a Content Writer at Hostinger, focused on creating and optimizing helpful, engaging articles about web development and marketing. With a background in journalism, he combines storytelling with practical insights to make complex topics easier to understand. He has also contributed to publications like MacMagazine and Jornal A Tarde. Outside of work, Bruno enjoys exploring art, cooking, and technology.

The post 10 best Manus alternatives in 2026 appeared first on WEBNET Hosting.

It’s easy to install an AI agent, run it with all the guardrails turned off, and only check the sandbox settings after it has changed a configuration file you needed. Codex provides three sandbox levels along with a separate approval policy. The combination you choose determines what it can access and modify.

So before getting into the useful stuff, we’ll install Codex, sign in, and then look closely at the flags that control what it can and cannot touch.

What Codex Does on a Linux Machine

Codex CLI is a local agent that works directly in your terminal. It can read your repository, suggest and make edits, run ls command, grep command, execute your test suite, and show you a diff of the changes it made.

For a sysadmin, that last part is especially important. Codex isn’t just a chat window that prints code for you to copy and paste; it can actually run commands in your shell and make changes on your system. That’s why the sandbox section below is worth reading carefully.

The examples in this guide were tested on Ubuntu 26.04 and RHEL 10. The commands should also work on any modern Linux distribution running on a 64-bit x86 or ARM system.

Install Codex CLI on Linux

The quickest way to install Codex CLI is with the official install script. It downloads a prebuilt binary and places it on your PATH.

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Here’s what each part of the command does:

• curl downloads the install script over HTTPS.
• -f makes curl fail on server errors instead of saving an HTML error page.
• -s runs silently, while -S shows real error messages.
• -L follows redirects used by the download endpoint.
• | sh sends the downloaded script directly to the shell for execution.

That last part comes with an important warning. Piping a remote script directly into sh means the shell executes whatever the server sends. If you’re installing Codex on a system you don’t own or manage, download the script first, review it, and then run it:

curl -fsSL https://chatgpt.com/codex/install.sh -o codex-install.sh

Then inspect the script before executing it.

If you prefer using Node.js, install Node.js and npm first. The package manager command depends on your distribution, so use the one that matches your system.

On Ubuntu/Debian:

sudo apt install nodejs npm

On RHEL/Rocky Linux:

sudo dnf install nodejs npm

sudo runs the command with root privileges. You need it here because the package managers may need to write to system directories. Without it, you may see a Permission denied error.

Once Node.js and npm are installed, install Codex CLI globally:

npm install -g @openai/codex

There’s also a third option if you don’t want to use a package manager; the latest GitHub release provides static binaries. On a 64-bit Intel or AMD system, download codex-x86_64-unknown-linux-musl.tar.gz, extract it, rename the binary to codex, and move it to a directory in your PATH.

Whichever installation method you use, verify that Codex is available:

codex --version

If you see a version number instead of command not found, Codex is installed and available on your PATH. If it isn’t, check the troubleshooting section near the end of the guide. In most cases, the problem is simply that the directory containing the binary isn’t in your PATH.

Sign In From a Headless Server

The first time you run codex, it asks you to sign in. On a desktop, Codex opens your browser and completes the ChatGPT OAuth sign-in automatically.

On a server you connect to over SSH, there’s usually no browser available to open. This is where the device authentication flow comes in:

codex login --device-auth

Codex displays a short code and a URL. Open the URL on your laptop, enter the code, and the server completes authentication without needing to launch a browser locally.

Codex is included with ChatGPT Plus, Pro, Business, Edu, and Enterprise plans, so signing in with your ChatGPT account is the usual approach. If you’re using Codex in automation instead, you can provide an API key through an environment variable:

printenv OPENAI_API_KEY | codex login --with-api-key

You can check your authentication status at any time:

codex login status

This shows the active authentication method and exits with status 0 when valid credentials are available, making it useful as a simple check at the beginning of a shell script.

Sandbox Modes: The Setting That Actually Matters

Codex separates two questions that are easy to mix up: What can the agent access? And when should it stop and ask you?

The sandbox controls the first question with --sandbox, or -s for short:

• read-only lets Codex read files and run commands that don’t modify anything. Nothing on disk is changed.
• workspace-write lets Codex modify files inside the current working directory, but not elsewhere.
• danger-full-access removes the sandbox boundary completely and allows commands to access anything your user account can access.

The approval policy controls the second question with --ask-for-approval, or -a:

• untrusted pauses for commands Codex doesn’t already consider safe.
• on-request lets Codex ask when it needs to perform an action outside the sandbox.
• never runs the entire session without asking for approval.

For everyday work in a repository, the combination worth remembering is:

codex --sandbox workspace-write --ask-for-approval on-request

This gives Codex enough access to edit code and run tests without asking for approval every few seconds, while still keeping it inside the directory where you started it. If it needs to access something outside that directory, you get a chance to approve it.

If the task genuinely requires access to another directory, grant access to that directory explicitly instead of weakening the sandbox:

codex --sandbox workspace-write --add-dir /var/www/

Angle brackets such as <your-site> are placeholders used throughout this article. Replace them with your actual value and remove the brackets.

The Flag You Shouldn’t Reach For

Codex also has a --dangerously-bypass-approvals-and-sandbox flag, aliased as --yolo, which disables both approval prompts and sandboxing. The name is a pretty good warning.

The safest place to use this flag is inside a container or a throwaway VM that is already isolated at the operating-system level. On a machine containing real data, workspace-write with on-request gives you a good balance of speed and protection.

Slash Commands Worth Knowing

Once you’re inside the terminal UI, type / to open the command popup. These are the commands you’ll use most often:

• /status shows the active model, approval policy, writable roots, and how much context you have left.
• /diff shows the Git diff of everything Codex changed, including files that Git isn’t tracking yet.
• /review asks Codex to review your working tree and look for behavior changes or missing tests.
• /compact summarizes the conversation so far and frees up context during a long session.
• /permissions changes the approval preset without restarting Codex.
• /model switches the active model before you start a more demanding task.

Run /status as soon as you start a session. It’s the quickest way to confirm that Codex is using the sandbox you expect. It can also help catch situations where an existing ~/.codex/config.toml setting is overriding the flags you passed on the command line.

Running Codex Against a Local Model

If you want to keep your code and requests on your own hardware, --oss lets Codex use a local model provider instead of OpenAI’s hosted models:

codex --oss --local-provider ollama

This sends requests to Ollama running on the same machine. LM Studio is also supported with --local-provider lmstudio:

codex --oss --local-provider lmstudio

The trade-off is performance and capability. Local models may not perform as well as hosted models, especially on larger or more complex coding tasks, but they give you more control over where your code and requests are processed.

Run Codex Non-Interactively With codex exec

The terminal UI works well when you’re sitting at the keyboard. For cron jobs, CI pipelines, and other tasks that need to run without a person watching, use codex exec, which is also available as codex e.

codex exec --sandbox read-only -o /tmp/audit.md "Summarise every systemd unit in this repo that runs as root"

Here’s what each part does:

• codex exec runs a single task and exits instead of opening the terminal UI.
• --sandbox read-only prevents the run from making changes, which is what you want for an audit.
• -o /tmp/audit.md saves the final response to a file that you can review, email, or commit.
• The quoted string is the prompt. If you use - instead, Codex reads the prompt from standard input.

Two more options become useful when you put Codex into scripts. --json outputs newline-delimited JSON events instead of formatted text, making it easy to pipe the output into jq and use the results in your script. --skip-git-repo-check allows Codex to run in a directory that isn’t a Git repository, which it otherwise refuses to use.

If a scripted run stops partway through and you want to continue instead of starting again, use:

codex exec resume --last

This resumes the most recent session from the current directory.

Tell Codex Your Rules With AGENTS.md

Codex reads an AGENTS.md file from the directory where it is working and uses it as a set of standing instructions. You can create a starter file from inside a Codex session with:

/init

This creates a basic scaffold in the current directory. Edit it to include the rules that matter for your project, such as which test command to run, which directories are generated and should not be edited manually, and any deployment step that Codex must never run automatically.

Once you’re happy with the instructions, commit the AGENTS.md file to your repository. That way, you don’t have to explain the same project conventions at the start of every session.

When Codex Won’t Start

The most common problem immediately after installation is a shell that can’t find the codex command.

codex: command not found

Both the install script and npm install -g place the codex binary in a directory that your current shell may not have picked up yet. Start by opening a new shell and try again. If the command still isn’t found, check where npm installs global binaries:

npm config get prefix

Then add the corresponding bin directory to your PATH in ~/.bashrc. Reload the shell and run:

codex --version

If it prints the version, your PATH is configured correctly.

Everything Else

Codex includes its own diagnostic command, which checks your installation, configuration, authentication, runtime, Git, and terminal setup in one pass:

codex doctor --summary

The --summary flag shows grouped check results and a final count instead of the full diagnostic report. That’s usually enough to quickly identify what’s wrong. When you need more detail, run the command without --summary. If you’re attaching the output to a bug report, add –-json; the JSON output is redacted.

There’s also a version-related detail worth knowing. The old --full-auto flag is deprecated and displays a warning, so use --sandbox workspace-write instead. Likewise, codex mcp-server has been replaced by the Codex app server.

Conclusion

You’ve now installed codex using a script, npm package, or static binary, signed in from a headless server with the device code flow, and learned how --sandbox and --ask-for-approval control what the agent can access and when it needs your approval.

You’ve also seen how codex exec lets you run tasks without the interactive terminal UI, making it useful for scripts and automation. Here’s a good way to start. Pick a repository you know well, run:

codex --sandbox read-only

Then ask Codex to explain a file you’re already familiar with. Because the session is read-only, it can’t modify anything. You can evaluate the quality of its answers before giving it permission to make changes.

What’s the first task you’d trust Codex with on a real server, and what’s the one you wouldn’t? Share it in the comments. The boundaries people set around these tools can be just as interesting as the tools themselves.

The post Codex CLI: Use OpenAI’s AI Coding Agent in the Linux Terminal appeared first on WEBNET Hosting.

Most people treat dnf as a drop-in replacement for yum and stop there. But that misses a lot of what makes DNF worth learning; automatic dependency resolution, transaction history with full undo support, module streams, and a plugin system that goes beyond what yum offered.

DNF (Dandified YUM) has been the default package manager on Fedora since Fedora 22 (2015) and on RHEL since RHEL 8 (2019). It is used across RHEL 8/9/10, Rocky Linux, AlmaLinux, CentOS Stream, and Fedora. If you’re still typing yum on any of these systems, it is usually linked or aliased to DNF anyway.

One important distinction for 2025/2026 is DNF5. DNF5 is a complete C++ rewrite of DNF and is now the default package manager on Fedora 41 and later, including Fedora 44, the current release.

On Fedora 41+, /usr/bin/dnf is a symlink to /usr/bin/dnf5 for backward compatibility, so the commands in this article still work. However, if you’re using Fedora 41 or later, writing dnf5 explicitly is recommended.

On the enterprise side, RHEL 9, Rocky Linux 9, AlmaLinux 9, and RHEL 10 still use DNF (dnf4) as the default package manager. DNF5 has not yet replaced DNF on these systems.

All examples below are tested on RHEL 9, Rocky Linux 9, and Fedora 44. A dedicated DNF5 section at the end of this article covers what changes on Fedora 41+.

Prerequisites: You need a working RHEL 8/9/10, Rocky Linux, AlmaLinux, or Fedora system. Most commands require sudo or root privileges; commands that don’t are noted accordingly.

1. Install a Package

sudo dnf install nginx

DNF automatically resolves and installs all required dependencies. You can also install multiple packages with a single command:

sudo dnf install git curl wget vim

To skip the confirmation prompt, use -y. This is especially useful in scripts:

sudo dnf install -y nginx

2. Remove a Package

sudo dnf remove nginx

This removes the package but does not automatically remove all of its dependencies. If you also want to remove packages that were installed as dependencies and are no longer required, use autoremove instead (see Example 8).

3. Update a Single Package

sudo dnf update nginx

In DNF, update and upgrade are equivalent. Both update packages and handle obsolete packages, so there is no practical difference between the two commands.

4. Update All Packages

sudo dnf update

This updates all installed packages to the latest versions available from your enabled repositories. Before making any changes, you can check whether updates are available:

sudo dnf check-update

check-update returns exit code 100 when updates are available and 0 when the system is up to date. This makes it useful in scripts and cron jobs.

5. Search for a Package

dnf search nginx

To search both package names and package descriptions, use:

dnf search all nginx

The results include the package name, architecture, and a short summary. You don’t need sudo for package searches.

6. Get Package Information

dnf info nginx

This displays details such as the version, release, architecture, installed size, source repository, summary, and description without installing the package.

To view information about a package that is already installed:

dnf info --installed nginx

7. List Installed Packages

dnf list --installed

To check whether a specific package is installed, filter the output with grep command:

dnf list --installed | grep nginx

To list packages available from your enabled repositories, whether installed or not:

dnf list --available

8. Remove Unused Dependencies

As you install and remove packages over time, some dependencies may no longer be needed. DNF can identify and remove these orphaned packages with autoremove:

sudo dnf autoremove

Run it periodically to keep your system clean. DNF only removes packages that were installed as dependencies and are no longer required by any installed package.

9. Clean the DNF Cache

DNF stores package metadata and downloaded RPMs in /var/cache/dnf. You can clean the cache if a repository is returning stale data or you’re running low on disk space:

sudo dnf clean all

To clean only the metadata while keeping downloaded packages:

sudo dnf clean metadata

After cleaning the metadata, the next dnf command downloads fresh metadata from all enabled repositories.

10. View Transaction History

DNF keeps a transaction history of package installations, updates, and removals. To view recent transactions:

dnf history

You may see output like this:

ID     | Command line                        | Date and time    | Action(s) | Altered
-------+-------------------------------------+------------------+-----------+--------
    12 | install nginx                       | 2026-08-14 09:31 | Install   |      3
    11 | update                              | 2026-08-12 14:05 | Upgrade   |     47
    10 | remove vim-enhanced                 | 2026-08-10 11:22 | Removed   |      1

Each transaction has a unique ID that you can use to inspect what happened. For example:

dnf history info 12

This shows the packages affected by transaction 12, along with additional transaction details.

11. Undo a Transaction

One of DNF’s most useful features is the ability to undo a previous transaction using its ID.

For example:

sudo dnf history undo 12

DNF attempts to reverse transaction 12. If the transaction installed three packages, those packages are removed. If it upgraded packages, DNF attempts to restore their previous versions.

You can also redo a transaction that was previously undone:

sudo dnf history redo 12

12. Downgrade a Package

If a newer package version causes problems, you can downgrade it to an older available version:

sudo dnf downgrade nginx

DNF selects the highest available version that is older than the currently installed version.

To install a specific version instead, specify the complete package version:

sudo dnf install nginx-1.24.0-1.el9.x86_64

13. Install a Local RPM File

If you’ve downloaded an RPM file manually, you can install it by passing its path directly to dnf install. Unlike rpm -i, DNF can resolve and install missing dependencies from your configured repositories:

sudo dnf install /tmp/package.rpm

14. List and Manage Repositories

To list all enabled repositories and their status:

dnf repolist

To see both enabled and disabled repositories:

dnf repolist --all

You can enable or disable a repository for a single command using --enablerepo and --disablerepo:

sudo dnf install --enablerepo=crb curl
sudo dnf update --disablerepo=epel

To permanently enable or disable a repository:

sudo dnf config-manager --enable crb
sudo dnf config-manager --disable epel

15. Add a New Repository

To add a repository using its URL:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Repository configuration files are stored in /etc/yum.repos.d/. After adding a repository, verify that it appears in the repository list:

dnf repolist

16. Install a Package Group

DNF supports package groups, which are collections of related packages that can be installed together. To see the available groups:

dnf group list

To install a group:

sudo dnf group install "Development Tools"

To remove a group:

sudo dnf group remove "Development Tools"

17. Work with Module Streams

Note: Module streams apply to RHEL 8/9, Rocky Linux, and AlmaLinux. Fedora retired modularity in Fedora 39, so on Fedora 40 and later, you install specific package versions directly from the repositories or use third-party repositories instead.

On RHEL 9 and Rocky Linux 9, DNF modules allow you to work with different versions of a package; for example, Node.js 18 or Node.js 20 without adding third-party repositories:

# List available module streams
dnf module list nodejs

# Enable a specific stream
sudo dnf module enable nodejs:20

# Install the module
sudo dnf module install nodejs:20

To switch to a different stream:

sudo dnf module reset nodejs
sudo dnf module enable nodejs:22
sudo dnf module install nodejs:22

On RHEL 10, module streams continue to be supported with an updated set of available streams. Run dnf module list on your system to see the current catalog.

18. Find Which Package Provides a File

When a command is missing, and you need to find out which package provides it, use dnf provides:

dnf provides /usr/bin/netstat
dnf provides */netstat

For example, the output may look like this:

net-tools-2.0-0.62.20160912git.el9.x86_64 : Basic networking tools
Repo        : baseos
Matched from:
Filename    : /usr/bin/netstat

This tells you that the net-tools package provides /usr/bin/netstat.

19. Reinstall a Package

If a package’s files are corrupted or accidentally deleted, you can reinstall the package without changing its version:

sudo dnf reinstall nginx

DNF downloads and reinstalls the same version that is currently recorded as installed.

20. Check and Verify Installed Packages

To check for broken dependencies across installed packages:

sudo dnf check

To verify the integrity of a specific package’s installed files against the RPM database, use:

rpm -V nginx

If everything is intact, the command produces no output. If you see any lines, they indicate files that differ from the original package. This can help identify accidental changes or corrupted files.

DNF vs YUM vs DNF5: Key Differences

DNF5 on Fedora 41 and Later

DNF5 is a ground-up rewrite of DNF in C++. It removes the Python dependency, processes metadata faster, uses less memory, and provides a cleaner, more consistent command-line interface.

DNF5 became the default package manager in Fedora 41, released in October 2024, and remains the default in later releases, including Fedora 44. On Fedora 41 and later, /usr/bin/dnf points to /usr/bin/dnf5, so the commands in this article continue to work as expected. However, using dnf5 explicitly is recommended going forward.

Most commands are the same in DNF and DNF5. Here are the differences worth knowing.

Install, Remove, and Update – Same Basic Syntax

sudo dnf5 install nginx
sudo dnf5 remove nginx
sudo dnf5 upgrade
sudo dnf5 upgrade nginx

With DNF5, upgrade is the preferred command for updating packages. update is still available as an alias, but upgrade is the canonical command.

Search and Info – Same Syntax

dnf5 search nginx
dnf5 info nginx

Repository Management – Slightly Different Flags

DNF5 includes config-manager as a built-in subcommand, so you don’t need a separate plugin for it.

To add a repository:

sudo dnf5 config-manager addrepo --from-repofile=https://download.docker.com/linux/rhel/docker-ce.repo

To enable or disable a repository:

sudo dnf5 config-manager setopt epel.enabled=1
sudo dnf5 config-manager setopt epel.enabled=0

Clean the Cache

To remove cached metadata and packages:

sudo dnf5 clean all

DNF5 uses check-upgrade as the preferred command instead of check-update. The older check-update command is still available as an alias.

What’s Not in DNF5 Yet

Module streams have only basic support in DNF5 on Fedora. Fedora retired modularity in Fedora 39, so this is generally not relevant to current Fedora releases.

On RHEL and Rocky Linux, DNF4 remains the default and provides full module stream support. DNF5 is not yet the default on RHEL 9, RHEL 10, Rocky Linux, or AlmaLinux, so use the standard dnf commands on those systems.

Quick Reference

Conclusion

DNF is much more than a replacement for yum. It gives you better dependency resolution, transaction history, package rollback, repository management, package groups, and tools for finding and troubleshooting packages.

For RHEL, Rocky Linux, AlmaLinux, and CentOS Stream, getting comfortable with dnf is an essential part of managing modern RPM-based systems. If you’re using Fedora 41 or later, you’ll also want to become familiar with DNF5 and its updated commands.

Once you know these commands, everyday package management becomes simpler, safer, and easier to troubleshoot whether you’re installing a single package or maintaining a production Linux server.

What’s the first DNF task you’d trust yourself to automate on a production server, and what’s the one you’d always run manually? Drop it in the comments the commands are simple, but knowing where to draw the line matters.

The post 20 DNF Commands Every Linux Administrator Should Know appeared first on WEBNET Hosting.

Before we begin, let me thank all our donors and sponsors. Many thanks to all of you for the help you’re providing us!

We’ve got new HWE ISOs this month and some really exciting news. As always, please be aware that the features and improvements mentioned in this blog are a work in progress and that this is a preview of what’s to come and what’s planned for the next release of Linux Mint.

HWE ISOs

A new set of HWE ISOs is available for Linux Mint 22.3 with kernel 7.0.

For more information on HWE, or to download these ISOs: https://www.linuxmint.com/hwe.php

Environment Variables

The System Administration tool received a new page dedicated to environment variables.

Variables defined on this page are set system-wide for all user sessions (graphical and/or console).

Kernel Management

Kernel management was removed from the Update Manager and re-implemented within the System Administration tool.

This new implementation supports both Linux Mint and LMDE. It focuses on kernel series rather than individual kernels.

Kernel management is very simple: You decide which series you want to track and how many older kernels you want to keep. You then receive kernel updates for your tracked series in the Update Manager, and older kernels are automatically removed by the system on a weekly basis.

If you need to free up space immediately, cleanups can be triggered manually.

You can also click on the History button to see which kernels were removed and when.

If you install a kernel from an unknown or custom series, the tool will list its series and give you the ability to mark it as tracked.

In the screenshot below, we installed an OEM and a Real Time kernel.

When you track a known series, the tool installs its meta-packages and ensures you receive updates for that series. In the case of a custom series, the tool doesn’t know how to do that and warns you that it is your responsibility to do so.

If a series is not tracked, all of its installed kernels get automatically removed during the next cleanup. Unless… you protect them.

You can click the “View all kernels” button to install, remove, or protect individual kernels.

When a kernel is marked as “protected”, it becomes immune to kernel cleanups and never gets deleted.

Keyboard Layouts and IM

Cinnamon received support for Fcitx5 with full Wayland/X11 parity.

With Fcitx5 selected in the Input Methods settings, Cinnamon no longer launches ibus-daemon, but uses a different internal handler instead. It lets you define a single layout and delegates everything else to Fcitx.

Cinnamon also features a new keyboard layout viewer.

This viewer replaces the gnome-kbd viewer, which was discontinued.

Other improvements

Interacting with the panel when working with fullscreen windows feels much more natural than before. You can click other components of the panel, close the menu, open other applets, etc.

Sponsorships:

A total of $14,761 were raised thanks to the generous contributions of 419 donors:

$580 (7th donation), Natalya S.
$464 (2nd donation), Michael S.
$300 (35th donation), John Mc aka “Land Research Project“
$300 (9th donation), André Inácio
$290, DJ
$250 (5th donation), Benjamin M.
$232, Dr. S. T.
$232, Götz K.
$145, Libre à Quimperlé
$128, Martin B.
$120 (8th donation), Michael P.
$116 (21st donation), Jiří B.
$116 (14th donation), Hans-Georg Thien
$116 (9th donation), Walter K.
$116, Jan K.
$116, Jan S.
$116, Martin D.
$116, OuestWare
$116, Richard L.
$116, Silvia S.
$116, Thomas E.
$116, Wolfgang H.
$100 (8th donation), William C.
$100 (3rd donation), abrames
$100 (3rd donation), Dale K.
$100 (3rd donation), Gilbert B.
$100 (3rd donation), Mark S.
$100, Adam S.
$100, Dan B.
$100, Edward R. K.
$100, Isaac K.
$100, Michael S.
$100, Services Multiples R.
$87 (2nd donation), Florian S.
$81, Benjamin S.
$75, Javier S.
$70 (6th donation), Vincent F.
$70 (3rd donation), ZS
$70, Simon H.
$58 (18th donation), Roland H.
$58 (17th donation), Jyrki A.
$58 (12th donation), Karl H.
$58 (7th donation), Gerald H.
$58 (5th donation), Karl-heinz P.
$58, Alexander H.
$58, Anton R.
$58, Bernd C.
$58, Daniel B.
$58, gilles Delaguette aka “gillou”
$58, Günter A.
$58, John P.
$58, Kai N.
$58, Levente D.
$58, Martin K.
$58, Michael T. B.
$58, Michel O.
$58, Nick V.
$58, Ralf E.
$58, Ralf S.
$58, Rene W.
$58, Rolando
$58, Rupert W.
$58, Ruth S.
$58, Sanny S.
$58, Stefan I.
$58, Thomas B.
$58, William A.
$58, William F.
$58, Yeun H. T.
$52, Jeffery M.
$51, John A.
$50 (21st donation), Mothy
$50 (17th donation), Anthony C. aka “Ciak”
$50 (11th donation), Peter L. aka “Pedro“
$50 (8th donation), Gerard S.
$50 (7th donation), Tim A.
$50 (6th donation), Leonhard R.
$50 (5th donation), Robert L.
$50 (3rd donation), Soeren
$50 (2nd donation), James M.
$50 (2nd donation), Jason E.
$50 (2nd donation), Johnny R. D.
$50 (2nd donation), peter T.
$50 (2nd donation), Timothy J I.
$50, Algie M.
$50, ANDREW M.
$50, Austin R.
$50, Caleb S.
$50, Dustin P.
$50, edward K. aka “edthefair”
$50, Gohér L.
$50, Joshua E.
$50, Lionel L.
$50, Maciej S.
$50, Marco M.
$50, Mark W.
$50, MOHD A. A. H.
$50, Richard A.
$50, Rolando G.
$50, Ruiping L.
$50, Samuel G.
$50, Shay C.
$50, vitalii V.
$50, Vitalox.co.uk
$50, Wayne L.
$50, WILSON N. S.
$50, Øyvind L.
$46, José R. B. U.
$46, Maik S.
$45, James R.
$41, M.J. D.
$40 (10th donation), Orlando O.
$40 (2nd donation), Jonathan L.
$40, Grant L. S.
$40, Joseph D.
$37, siobhan M.
$36, Shawn D.
$35 (3rd donation), Renee M.
$35, achim M.
$35, David B.
$35, Donald B.
$35, Fazekas F.
$35, GARRY J. W.
$35, Helmut E.
$35, P J. C.
$35, Russell R.
$35, Simon H.
$35, Teo S.
$35, Tobias K.
$35, vincent R.
$31 (6th donation), David B.
$31, Johannes W.
$30 (8th donation), Doug S.
$30, David S.
$30, Jan V. D.
$30, MR G. S.
$30, Terence R.
$29 (2nd donation), Askeldaja
$29 (2nd donation), Kerry H.
$29, Andrea P.
$29, Andrew G.
$29, Michael Koch
$29, Mr T. A.
$29, Warren B.
$28 (4th donation), Toon V.
$27, Benjamin B.
$25 (64th donation), Linux Mint Sverige
$25 (19th donation), Donna B.
$25 (17th donation), John N.
$25 (6th donation), Oleksandr N.
$25 (2nd donation), Roger M.
$25, John H.
$25, Ong L. Z.
$25, ROBERT A. B.
$23 (119th donation), Johann J.
$23 (78th donation), Bryan F.
$23 (72nd donation), Peter E.
$23 (39th donation), Stefan W.
$23 (34th donation), Benjamin W. aka “UncleBens”
$23 (32nd donation), Marek S.
$23 (14th donation), Frank W.
$23 (8th donation), Tapani H.
$23 (6th donation), Robert J.
$23 (4th donation), Guillaume P.
$23 (4th donation), Jeff H.
$23 (4th donation), Pedro A.
$23 (3rd donation), Adam B. aka “Neomodus”
$23 (3rd donation), Benjamin L.
$23 (3rd donation), Gehova L.
$23 (3rd donation), Systemutvikler R. S.
$23 (3rd donation), Thomas H.
$23 (2nd donation), Henrik M.
$23 (2nd donation), Ian K.
$23 (2nd donation), Michel S.
$23 (2nd donation), Norbert E.
$23 (2nd donation), Pascal T.
$23 (2nd donation), Peter V. R.
$23 (2nd donation), Z A. Z. A.
$23, aka “Dealer Dahl”
$23, Andreas S.
$23, Anonymous
$23, Dan M.
$23, Frédéric B.
$23, Heinz-Jürgen F.
$23, Helmut M.
$23, Henning G.
$23, Henrik H.
$23, J.P. G.
$23, Jochen H.
$23, johan B. aka “Woody”
$23, Johannes A.
$23, John M. S.
$23, Klaus P.
$23, Marcus B.
$23, Martin E.
$23, martine P.
$23, Michael N.
$23, michael P.
$23, Mr L. W.
$23, Nurbol K.
$23, Paolo R.
$23, Randy Lahey
$23, Riccardo B.
$23, Ronald H.
$23, Sebastian B.
$23, Sonja S.
$23, staffan O.
$23, Thomas B.
$23, Tobias E.
$23, WILFRIED H.
$23, Wolfgang M. S.
$21 (6th donation), James H.
$20 (53rd donation), John D.
$20 (31st donation), Denis D.
$20 (16th donation), Michel S.
$20 (12th donation), Randall W.
$20 (9th donation), Leela A.
$20 (9th donation), Ricardo M.
$20 (7th donation), Michael G.
$20 (5th donation), Gary S.
$20 (5th donation), Nathan B. aka “Diginate “
$20 (3rd donation), Theodore K.
$20 (2nd donation), Dmytro Z.
$20 (2nd donation), Jerome P.
$20 (2nd donation), Richard L. S.
$20 (2nd donation), Stephen B.
$20 (2nd donation), Terrence C.
$20, Aaron A.
$20, any N.
$20, Brian P.
$20, Bryan J.
$20, David S.
$20, Elijah W.
$20, Elizabeth H.
$20, Gervase G.
$20, GLEATON’S
$20, HYUNGU H.
$20, James M.
$20, Jay G.
$20, Jim B.
$20, Martin J.
$20, Michael B.
$20, Paul B.
$20, Randi J. R.
$20, Revd. Barry Keal aka “G4HDU“
$20, Richard J.
$20, RICHMOND D.
$20, Robert H.
$20, Ron H.
$20, Samuel K.
$20, Steve T.
$20, The Best Buy
$20, Thomas F. aka “Tom”
$17 (93rd donation), Andreas S.
$17 (8th donation), Tristan V.
$17 (5th donation), Tomasz S.
$17, Álvaro V.
$17, Michal L.
$15 (9th donation), mitch K.
$15 (4th donation), Snorre L.
$15 (2nd donation), Justin C.
$15, Josephine
$13 (19th donation), Alessandro S.
$12 (56th donation), Francois-R L.
$12 (51st donation), Thomas Rehm
$12 (50th donation), Tugaleres.com
$12 (30th donation), Adian K.
$12 (24th donation), Slobodan Vrkacevic
$12 (22nd donation), Eskild T
$12 (18th donation), Abe Z.
$12 (17th donation), Artem Ignatyev aka “ZaZooBred”
$12 (17th donation), Tomi P.
$12 (12th donation), Intralogistiker
$12 (8th donation), Rainer B.
$12 (7th donation), J M. H. C.
$12 (6th donation), Claudio A.
$12 (6th donation), Stefan B.
$12 (5th donation), Lyuben R.
$12 (5th donation), Olivier R.
$12 (5th donation), ronald H.
$12 (4th donation), Bartomiej T.
$12 (4th donation), Matthias K.
$12 (4th donation), Renaud A.
$12 (3rd donation), Arne A
$12 (3rd donation), Donald B.
$12 (3rd donation), FrankFRL
$12 (3rd donation), Raul Z.
$12 (2nd donation), Brian C.
$12 (2nd donation), Frank F.
$12 (2nd donation), Marc L.
$12 (2nd donation), MorpurgoMedia.nl aka “Morpurgo Media“
$12 (2nd donation), Nektarios T.
$12 (2nd donation), Ricardo O.
$12 (2nd donation), Sebastian M.
$12, –
$12, Antonio A. M.
$12, Antonio S.
$12, Bernhard R.
$12, Bettina B.
$12, Bogdan D.
$12, Christian B.
$12, Christoph A.
$12, Claes C.
$12, David P. B.
$12, Esteve L. G.
$12, Eugen W.
$12, Fidel V.
$12, FLORIAN K.
$12, Giobatta L.
$12, Helmut S.
$12, Henning S.
$12, Igor C.
$12, Jan O.
$12, Jesse D. A. R. D. S. J.
$12, Joe S.
$12, John D.
$12, Kalin S.
$12, Karel J.
$12, Klaus D. N.
$12, Koski M. K. aka “Wintageman“
$12, Lauris S.
$12, Mark C.
$12, Markus B.
$12, martin G.
$12, Michael D.
$12, Neil G.
$12, Noel A.
$12, Ralph A. W.
$12, Renzo M.
$12, Ruben O. K.
$12, Steffen H.
$12, Sven S.
$12, Tamás R. V.
$12, Thomas L.
$12, tj J.
$12, Wolfram S.
$11, Jozef T.
$10 (123rd donation), Thomas C.
$10 (65th donation), Philip Woodward
$10 (43rd donation), Sami Mannila
$10 (19th donation), Thevirtua
$10 (14th donation), Mariusz B.
$10 (9th donation), Korora Solutions
$10 (9th donation), Steven L.
$10 (6th donation), S Russo
$10 (6th donation), Selwyn A.
$10 (5th donation), makeup
$10 (4th donation), Earl R.
$10 (4th donation), notariat
$10 (3rd donation), narghilea
$10 (3rd donation), Richard W.
$10 (2nd donation), Daniel R.
$10 (2nd donation), Jacek B.
$10 (2nd donation), Metehan K.
$10 (2nd donation), Timothy C.
$10 (2nd donation), VPRECA
$10 (2nd donation), William P.
$10, B P.
$10, Brody McDonald
$10, Cesar R. B.
$10, Craig D.
$10, Dean D.
$10, Hector G. G.
$10, Michael S.
$10, NEWT L. H.
$10, Roger L.
$10, Seth A.
$10, Szilvia D.
$10, Timoth O.
$10, Vasilis A.
$10, Victor M. aka “Bull”
$10, William R.
$177 from 45 smaller donations

If you want to help Linux Mint with a donation, please visit https://www.linuxmint.com/donors.php

Patrons:

Linux Mint is proudly supported by 2,353 patrons, for a sum of $5,318 per month.

To become a Linux Mint patron, please visit https://www.patreon.com/linux_mint

The post Monthly News – July 2026 appeared first on WEBNET Hosting.

Continuous integration (CI) automatically builds and tests code changes, while continuous deployment automatically publishes every change that passes those checks to production – the live app that users access. This speeds up releases, but a missed error can also reach users without a final human check.

For example, a developer pushes code to GitHub. CI builds the app and runs its tests. If a test fails, the process stops so the developer can fix it. If every check passes, the change is ready to release. These automated steps form a pipeline – the path code follows from a developer’s update to the live app.

Continuous delivery is a process that sits between the two. It prepares a production change but waits for someone to approve the release.

CI covers automated builds and tests, but releasing the app still needs its own process – manual, continuous delivery, or fully automatic with continuous deployment. Continuous deployment suits teams that release small changes and can quickly spot and roll back a failure.

The hosting setup needs to support that process too: managed web app hosting handles server configuration and deployment automation for you, while a VPS gives you full control over your own tools and pipeline settings.

What is continuous integration?

Continuous integration means developers merge small code changes regularly, and each change is built and tested automatically.

Developers still write, review, and merge the code. CI runs repeated checks to verify that the new code works with the rest of the application.

For example, a developer pushes a feature to GitHub and opens a pull request. A pull request asks the team to review the change before adding it to the main branch, which holds the current shared version of the project.

The CI system then:

• Installs the software packages the app needs
• Runs the build command that prepares the app to run
• Checks the code for errors
• Runs automated tests
• Reports whether the change passed or failed

If a check fails, the pipeline stops there. The developer can fix that one change before it gets mixed with more work.

Without CI, developers can work separately for days or weeks before combining their changes. One update can then conflict with another, and finding the cause takes longer because the team has to inspect a large batch of code.

Once all checks pass, CI can package the code for the next stage. This package is called a build artifact.

A build artifact is a version of the application that’s ready for more testing or release. It can be a compiled program, a ZIP archive, or a container image built withDocker.

The CI stage doesn’t decide whether that package goes live. The same platform can also handle delivery or deployment, depending on how the workflow is set up. From there, the team can release the package manually, require approval through continuous delivery, or deploy it to production automatically via continuous deployment.

What is continuous deployment?

Continuous deployment automatically deploys every change that passes the required checks to production.

The process starts after CI builds and runs tests. The deployment system updates the live app and checks that the new version starts correctly.

Suppose a developer merges a tested change into the production branch. The deployment system detects the update, gets the approved version of the app, and publishes it.

No one has to click a release button or wait for a planned release window. Passing every required check is enough to start the deployment. A managed platform such as Hostinger Web Apps Hosting can handle this build-and-deploy step whenever approved code is pushed to the connected GitHub branch.

That saves time, but it removes the final production approval. Developers can still review the code before it’s merged. Teams using continuous deployment need safeguards that can catch and reverse failures quickly:

• Reliable automated tests that block changes that break important features
• A staging environment – a separate copy of the app used for final checks – that closely matches the live app
• Monitoring that tracks errors and performance after release
• A tested rollback process that restores the previous working version
• Access controls that limit who can change the pipeline and production settings

If the tests miss a defect, that defect reaches users automatically. Monitoring needs to spot the failure quickly, and rollback needs to restore the working version before more users are affected.

Where does continuous delivery fit?

Continuous delivery sits between continuous integration and continuous deployment. After CI builds and tests the code, continuous delivery packages the passing version and runs the remaining release checks, often in a staging environment. The app is then ready for production.

What happens next separates continuous delivery from continuous deployment:

• Continuous delivery – someone approves the release before it goes live.
• Continuous deployment – the release goes live automatically after every check passes.

The rest of the process can stay automated in both cases. Developers shouldn’t need to copy files, change server settings, or run deployment commands by hand.

Continuous delivery works well when a team needs control over release timing. A company might need to prepare customer support, publish release notes, schedule maintenance, or record formal approval before updating the live app.

What is the difference between continuous integration vs. continuous deployment?

Continuous integration checks whether a code change works, while continuous deployment automatically deploys a passing change to the live app.

Continuous delivery connects those two stages. It prepares the production change but requires manual approval before release.

Here’s how continuous integration vs. continuous deployment compare, along with the role that continuous delivery plays between the two:

You can use CI without continuous deployment. A team might test every pull request automatically, but still release the app manually once a week.

Continuous deployment depends on CI because it needs a reliable way to decide whether a change is ready for users. Without automated builds and tests, the system would release unchecked code.

The same tool can cover more than one stage. GitHub Actions, GitLab CI/CD, and Jenkins can all run builds, tests, and deployments. The workflow settings and production approval rules determine whether the team is using continuous integration, continuous delivery, or continuous deployment.

These stages manage how code moves toward production, but they don’t cover everything needed to run an application reliably. A widermodern DevOps process also covers server setup, security, monitoring, and feedback from the live app.

Advantages of continuous integration

CI gives developers faster feedback by building and testing each code change before release.

• Errors are found earlier. Developers see failed builds and tests while the change is still small.
• Merge conflicts stay smaller. Frequent updates stop separate branches from drifting too far apart.
• Builds are more consistent. The same commands and checks run for every change.
• Broken changes stop before release. A failed check prevents the code from moving to the next stage.

Limitations of continuous integration

CI checks code, but it doesn’t manage the production release.

• It only catches errors covered by tests. An untested feature can still break.
• Slow checks delay merges. Developers have to wait when the pipeline takes too long.
• Flaky tests create false failures. Teams waste time rerunning checks that fail without a code change.
• Deployment still needs a separate process. Passing CI doesn’t send the app to production. You still need to decide where and how tohost a web application.

Advantages of continuous deployment

Continuous deployment releases passing changes without waiting for someone to start each production update.

• Changes reach users faster. A passing update can go live as soon as the pipeline finishes.
• Releases stay smaller. Fewer changes go live at once, making failures easier to trace.
• Teams do less repeated release work. Developers don’t need to copy files or run deployment commands by hand.
• User feedback arrives sooner. Teams can see how each update performs in the live app shortly after release.

Limitations of continuous deployment

Continuous deployment removes the final approval step, so automated tests, monitoring, and rollback have to do the work a human approver used to do.

• Missed defects reach users automatically. Weak tests can allow a broken change into production.
• Some updates are hard to reverse. Database changes and other permanent actions can complicate rollback.
• Monitoring and rollback must be reliable. The team needs to detect failures and restore a working version quickly.
• Some releases still need coordination. Maintenance windows, customer notices, or required approval can make continuous delivery a better choice.

When should you use CI, continuous delivery, or continuous deployment?

Choose the highest level of automation your tests and production safeguards can handle reliably.

Before removing production approval, check whether your automated safeguards can take over the checks a person previously handled:

• Do your tests cover the features customers depend on?
• Does the pipeline stop when an important test fails?
• Will monitoring alert the team soon after the live app starts failing?
• Can you restore the previous version quickly?
• Are the releases small enough to test and reverse without a long recovery?

Stay with continuous delivery if any answer is no. Manual approval gives your team another chance to review the release while you implement the missing safeguard.

Move to continuous deployment once releases are small, failures are easy to trace, and the previous version can be restored quickly.

Best practices for CI/CD pipelines

A reliable CI/CD pipeline must catch broken changes before release, protect sensitive access, and make failed deployments easy to trace and reverse. Use these best practices to strengthen each part of the process.

• Test different parts of the application. Unit tests check individual functions. Integration tests confirm that the app’s separate parts work together. End-to-end tests repeat an important user action, such as signing in or completing a purchase. Submit a change that breaks a known test to check the pipeline. It should fail and stop the deployment.
• Use a staging environment. Staging is a separate copy of the app used for final checks before production. Keep its software versions and settings as close as possible to the live environment. Test database updates, logins, forms, payments, and other important actions before release.
• Keep passwords and keys out of the code. Store database passwords, API keys, and login tokens in environment variables or a protected secret manager. Environment variables provide these settings when the app starts, so they don’t need to appear in the repository. If a secret enters Git history, remove it and replace it because older commits can still expose it.
• Store pipeline settings with the code. Keep build commands, deployment instructions, and server configuration in version control, which records every change. The team can then review those updates and restore an earlier version if needed.
• Prepare rollback before automating releases. Rollback restores the previous working version after a failed deployment. Keep that version available and write down how to restore it. Test the process in staging by deploying a controlled failure and confirming that the earlier version returns successfully.
• Log every deployment. Record the code version, deployment time, test results, and pipeline run behind each release. If the app starts failing, these records show what changed and when.
• Monitor the app after every release. Track server errors, response times, resource use, and important customer actions. For an online store, the home page might work while checkout requests fail. Your alerts need to catch that failure, not just confirm that the server is running.
• Limit access to the pipeline. Give each person access only to the settings they need. Restrict who can edit build files, production branches, passwords, and deployment rules. Keep an audit log to see who changed a setting and when.

Most CI/CD setups use one tool to store the code, another to test it, and a hosting platform to publish the app.

GitHub or GitLab holds the repository. GitHub Actions, GitLab CI/CD, or Jenkins runs the builds and tests. A hosting platform then deploys the version that passes those checks.

For developers and small teams who don’t want to maintain a server, Hostinger Web App Hosting can take care of that deployment stage for Node.js apps.

You candeploy a Node.js application from GitHub, a ZIP file, or a supported development tool through Hostinger Connector. With GitHub connected, every push to the selected branch starts a new build and deployment.

That automatic trigger makes GitHub the most relevant option for this CI/CD example. A GitHub-to-Hostinger workflow can look like this:

1. A developer opens a pull request.
2. GitHub Actions builds and tests the change.
3. GitHub blocks the merge if a required check fails.
4. A passing change reaches the branch connected to Hostinger.
5. Hostinger builds the app and publishes the new version.

Set up branch protection in GitHub so only changes that pass CI can reach the connected branch. Hostinger deploys whatever is pushed there, so an unprotected branch could send untested code to production.

After youconnect your Node.js project, hPanel lets you:

• Change the build and start commands
• Add environment variables, including database credentials
• Check build logs when deployment fails
• Check runtime logs after the app starts
• Redeploy the latest code
• Restart server-side apps
• Review dependency vulnerabilities and apply available fixes

ChooseHostinger VPS when you need to install Jenkins, run GitLab Runner, manage Docker containers, use GitHub Actions, or create a custom CI/CD pipeline. You get full control over the setup, but your team also has to maintain the server and deployment tools.

All of the tutorial content on this website is subject to

Hostinger’s rigorous editorial standards and values.

The author

Alma Fernando

Alma is an AI Content Editor with 9+ years of experience helping ideas take shape across SEO, marketing, and content. She loves working with words, structure, and strategy to make content both useful and enjoyable to read. Off the clock, she can be found gaming, drawing, or diving into her latest D&D adventure.

The post Continuous integration vs. continuous deployment: What is the difference? appeared first on WEBNET Hosting.

Development and project teams can use Buzz to coordinate sprints, assign coding tasks to AI agents, triage bugs, review code, automate recurring workflows, and keep project communication in one place. These use cases help teams reduce tool switching and maintain context as work moves from planning to implementation and review.

Buzz combines team communication, code collaboration, and AI-powered workflow automation in a free, open-source workspace. Teams can use either the hosted version or deploy Buzz on their own infrastructure.

The platform is built around AI agents that can plan tasks, complete steps independently, and share their results in the same channels where the team discusses the project. This makes Buzz particularly useful for workflows that involve repeated handoffs between developers, project managers, reviewers, and automated agents.

However, Buzz is still in its early stages. Block describes the project as rough around the edges, so teams should expect its features and workflows to continue changing as the platform develops.

1. Coordinating software development projects

Buzz gives development teams a shared workspace for planning sprints, discussing architecture decisions, tracking progress, and keeping project context together.

Use Buzz as a shared workspace for sprint planning, daily coordination, and project decisions. This keeps important context in one place instead of spreading it across chat threads, issue trackers, and email. Engineering managers, tech leads, and cross-functional product teams can therefore work from the same project information.

How humans and AI work together

Team members discuss tasks and priorities in threaded conversations. AI agents could potentially summarize discussions, surface relevant past decisions, and flag blockers.

Each developer posts a daily update in the project channel. An AI agent can combine these updates into a short end-of-day summary. The tech lead can then review a summary instead of reading every discussion thread.

Buzz features for project coordination

• Persistent threaded channels keep sprint discussions organized by topic.
• Searchable project history makes past decisions easy to find.
• The ability to add an AI agent to a channel, giving it the same access to the conversation history a person would have.

How Buzz improves project coordination

Sprint context ends up in one searchable place. Decisions, trade-offs, and status updates are less likely to get scattered across multiple tools.

Limitations of using Buzz for project coordination

Buzz includes Git hosting and code review workflows, but it isn’t a full project management tool. It doesn’t provide a dedicated issue tracker or enterprise project management features such as Gantt charts or resource allocation, so teams that rely on those capabilities will still need a separate tool.

Buzz is still in its early stages, launched in July 2026. Several features are still unfinished, including mobile clients and workflow approval gates. Sprint coordination is a reasonable use case for Buzzis design, though specific sprint management features like backlogs or velocity tracking aren’t officially documented yet.

2. Running multi-agent coding tasks

You can assign coding tasks to AI agents that operate within the Buzz workspace, going beyond simple code-completion tools that suggest individual lines of code.

Use Buzz agents to automate repetitive development work. Typical tasks include generating project setup code, refactoring legacy code, writing tests, and migrating projects to newer systems. AI agents provide the most value when they can independently complete these clearly defined, multi-step tasks.

A developer describes the task in natural language in a channel, and an AI agent carries out the work and posts results back for human review.

How humans and AI work together

Buzz uses Agent Client Protocol (ACP) to connect with agent frameworks such as goose, Codex, and Claude Code. These frameworks can read a codebase, modify multiple files, run tests, and report the results in a Buzz channel.

For example, a developer can ask an AI agent to add input validation to every API endpoint in a microservice. The agent scans the codebase and identifies missing validation logic. It then writes the required logic and unit tests before posting a summary for human review.

Buzz features for multi-agent coding

• Agent Client Protocol connects Buzz to external coding agents.
• Channel-based reporting lets agents post results where the team can see them.
• Natural language task assignment lets you describe the job instead of typing commands.

How multi-agent coding benefits developers

Routine, time-consuming coding tasks get completed faster while developers focus on higher-judgment work. Buzz provides the workspace and communication layer, while the agent framework handles the coding.

Limitations of multi-agent coding in Buzz

Actual results depend on the agent’s capabilities and the codebase’s complexity. Always review agent-generated code before merging. Specific capabilities are still taking shape as the platform matures.

Multi-agent coding is one example of AI agents used in workflows where AI handles execution and humans verify the output.

3. Searching project history and retrieving context

Buzz’s searchable workspace lets you find past conversations, decisions, code discussions, and the reasoning behind them across your entire project history.

Catch up on a project’s history or understand why past decisions were made, without interrupting teammates for context. In most chat apps, old messages get buried and forgotten. When someone joins a project mid-cycle or needs to revisit why a technical decision was made, the information is either gone or locked in someone’s memory.

How humans and AI work together

A team member types a search query and finds the original conversation. An AI agent could potentially help by summarizing long threads or pulling together related discussions from different channels.

For example, a new team member may need to know why the team chose PostgreSQL instead of MongoDB. They can search Buzz and find the original decision-making conversation. This gives them the required context without interrupting a senior engineer.

Buzz features for retrieving project context

• Cross-channel search covers every channel and thread in the workspace.
• Persistent message history means old conversations don’t disappear.
• The ability to add an AI agent to a channel and ask it to help make sense of a long discussion.

How searchable project history benefits teams

Institutional knowledge becomes easier to access rather than being lost in old chat logs. New team members can get up to speed without pulling senior engineers away from their work.

Limitations of Buzz project search

Buzz search uses PostgreSQL full-text matching and supports basic stemming. For example, a search for “running” can also match “run.” However, it does not automatically connect conceptually related terms, so “login” may not return a discussion about “authentication.”

Buzz can only retrieve information recorded in its workspace. Decisions made in private messages, external meetings, or video calls will remain unavailable unless someone documents them in Buzz.

Buzz is still in Developer Preview as of early August 2026, so treat it as an emerging tool for context retrieval rather than a production-ready knowledge base.

4. Triaging bugs and issues

Buzz can serve as a coordination layer where bug reports are received, categorized, prioritized, and assigned within the same workspace where development conversations happen.

Bug reports may come from quality assurance engineers, users, or monitoring tools. The triage lead checks each report for duplicates, assesses its severity, and assigns it to the appropriate developer. The assignment should include enough context for the developer to begin investigating immediately.

How humans and AI work together

Bug reports go into a dedicated channel. An AI agent could potentially analyze the report, suggest severity levels, and recommend who should investigate. The triage lead reviews the agent’s suggestions and confirms or adjusts assignments.

Before assigning a bug, the triage lead searches past channels for similar issues. A QA engineer submits a bug report with reproduction steps, and a quick search shows a similar issue that was reported and fixed two sprints ago. The triage lead recognizes it may be a regression and assigns it to the original developer with full context attached.

Buzz features for bug triage

• Dedicated triage channels keep bug reports organized and visible.
• Searchable issue history lets developers manually check for similar past reports before assigning, which is faster than digging through most chat tools.
• The ability to link directly to past discussions and fixes when assigning a bug, so the new developer doesn’t have to go looking for them.

How Buzz improves bug triage

Faster triage with better context reduces the time between bug report and developer assignment. The conversation history around past fixes gives developers a head start.

Limitations of triaging bugs in Buzz

Buzz does not provide automated duplicate detection. Teams must search manually for similar reports. Because the search relies on keywords, it may miss duplicate issues described with different terminology.

Buzz also lacks specialized functions such as service-level agreement tracking and customer-facing status pages. Teams that need these capabilities should continue using a dedicated issue-management platform.

These bug-triage workflows show how Buzz channels and connected AI agents can work together. However, Buzz does not currently document them as built-in bug-triage features.

5. Reviewing code collaboratively

Buzz lets you conduct code reviews using an integrated Git forge, where AI agents provide automated feedback, and approval decisions are documented alongside the project conversation.

Use Buzz’s Git integration to coordinate code reviews. A connected AI agent can complete the initial mechanical review by identifying potential bugs, checking coding style, and evaluating test coverage. Human reviewers can then focus on architecture, design decisions, and application logic.

How humans and AI work together

Code hosting and review happen natively within the platform. A developer shares changes in a channel, and AI agents you’ve configured can review them for common issues, style violations, and test coverage gaps. Senior engineers then focus on architecture and logic.

Buzz does not provide a built-in, one-click pull request review. Teams must configure an external agent framework, such as Claude Code or goose, to review the changes and post findings in a channel.

For example, a developer posts a pull request summary. The configured agent identifies missing tests for two edge cases and flags a possible null-pointer issue. A senior engineer verifies the findings and adds architectural feedback.

Buzz features for collaborative code review

• Integrated Git forge keeps code hosting and review inside the workspace.
• The ability to connect an agent framework like Claude Code or goose to review pull requests and post findings directly to the channel.
• Threaded discussions tie review feedback to the relevant conversation context.

How Buzz improves collaborative code review

AI handles the mechanical parts of code review, freeing your team to focus on design and logic. Review feedback lives alongside the project conversation rather than in a separate tool.

Limitations of reviewing code in Buzz

Buzz’s built-in Git integration and Forge interface are still at an early development stage. Teams should evaluate their current functionality rather than rely on expected future improvements.

Workflow approval gates are not yet functional in production. A workflow that requests human approval currently fails instead of pausing for a response. Therefore, Buzz does not yet support formal review processes that require human approval before a pull request is merged.

Teams using GitHub or GitLab should evaluate these limitations before migrating their review workflows to Buzz.

AI review quality also depends on the configured agent. Automated reviews may identify common errors and edge cases, but they do not replace experienced human review of critical code paths.

6. Automating recurring processes

Buzz workflows use YAML definitions and can be triggered by a schedule, message, reaction, or webhook. Basic workflows can post updates without using AI.

Teams can also connect an AI agent to handle tasks that require analysis or synthesis. For example, an agent can turn daily updates into a standup summary, audit outdated dependencies, or draft a team report.

Use Buzz to automate repetitive coordination tasks such as collecting, formatting, and publishing team updates. These tasks are predictable but time-consuming when completed manually. Automation also reduces the chance that teams will skip them during busy periods.

How humans and AI work together

A team member first creates a YAML workflow with a scheduled trigger. The workflow posts a message in the relevant channel and mentions a connected AI agent. For example, it can send a daily prompt requesting a standup summary.

The agent receives the mention through the separately configured ACP harness. It compiles the required information and posts the result in the channel. Team members review the output and adjust the schedule or the agent configuration as needed.

This setup requires technical configuration. Teams must work with the ACP harness, Nostr key pairs, and YAML workflow syntax. Developers familiar with these technologies can configure the automations, while non-technical users will likely need technical support.

An engineering team could configure an agent to compile a daily standup digest by reading posted updates and flagging blockers. Another agent checks for outdated dependencies weekly and posts a summary ranked by severity.

Buzz features for workflow automation

• YAML-based scheduled triggers let agents run tasks on a defined cadence.
• Channel-based output posts results that the team will see.
• Configurable agent tasks mean you define what gets automated and how.

How Buzz benefits recurring workflows

Routine coordination tasks can run on a schedule without manual effort. Start with one or two automations and expand based on what your team actually needs.

Limitations of automating workflows in Buzz

Buzz does not currently provide prebuilt templates for these automations, so teams must configure each workflow manually. Approval gates are not fully functional in version 0.4, and some workflow actions remain incomplete. Teams should test every automation before using it for an important process.

Scheduled triggers can automate recurring workflows, but their reliability depends on the agent and workflow configuration. Agent uptime is particularly important for time-sensitive processes such as deployment notifications.

7. Keeping project discussions and decisions in a single workspace

Buzz can consolidate project-related communication into one searchable workspace, covering technical discussions, decision records, design debates, and stakeholder updates.

Use Buzz to keep technical discussions, project decisions, and design debates in one workspace. This prevents important context from being distributed across email, chat applications, wikis, and meeting notes. Team members can then find what was agreed and why the decision was made without searching several tools.

How humans and AI work together

Teams can organize Buzz channels by project or topic. Connected AI agents can summarize long discussions and extract action items. They can then add the results to a canvas, which is a shared document attached to the channel. The canvas can serve as an ongoing decision log.

For example, a product team can create a dedicated channel for each feature. When a discussion exceeds 50 messages, a configured agent can summarize the main positions. It can post the summary in the channel or add it to the project canvas. This preserves the rationale for the decision after the original discussion ends.

Buzz features for centralizing project communication

• Project-organized channels group discussions by topic or feature.
• Configurable AI agents can summarize long discussion threads into key decisions and action items, although this requires configuring an agent rather than relying on a built-in summarization feature.
• MCP tool integration lets agents create structured outputs like decision logs.

How a shared workspace benefits project teams

Decisions and their context stay preserved and findable. New team members can piece together a project’s history in one place instead of chasing it across several different tools.

Limitations of centralizing project communication in Buzz

These capabilities come from the agent framework rather than Buzz natively, so they require setup. Teams transitioning from other tools should also set clear norms about what gets discussed in Buzz. If conversations still happen elsewhere, the workspace will have gaps.

Buzz is still in its early stages and isn’t production-ready for most teams yet. Treat it as a promising consolidation tool rather than a guaranteed replacement for your current knowledge management setup.

How to decide which Buzz use cases fit your team

The best way to decide is to work through a few questions about your team, your current tools, and how much risk you’re comfortable taking on with an early-stage platform. Start with whichever use cases score lowest on risk and expand from there:

• How big is your team? Smaller teams may prefer the all-in-one workspace approach, while larger teams with specialized roles might start with targeted use cases like multi-agent coding or automated triage.
• How many tools are you juggling? The more tools your team switches between for communication, code review, task tracking, and documentation, the more consolidation can help.
• How comfortable is your team with AI agents? Teams experienced with AI agents working alongside humans in shared workflows can adopt agent-heavy setups right away. If you’re new to how agentic AI plans and acts toward a goal, start with AI-assisted search or summarization and build from there.
• Do you already have established workflows? Teams with existing code review and triage processes can layer Buzz on top of them. Teams building processes from scratch can use Buzz as their foundation.
• Do you need control over where your data lives? Self-hosting gives you full control but requires standing up a Nostr relay, managing Rust and Node dependencies, and dedicated DevOps capacity. The Block-hosted version is simpler, though your data resides on Block’s infrastructure.
• Are you willing to invest time in setting up automation? Recurring automation requires upfront configuration. Teams that prefer manual control can still use Buzz’s communication and search features.

Can non-developers use Buzz?

Yes, non-developers can use Buzz. Project managers, product managers, and other team members can use its communication and search features. They can also interact with connected AI agents via natural-language instructions for tasks such as summarizing discussions.

AI agent interactions use natural language, so technical expertise isn’t required for many workflows.

Buzz offers a desktop app for macOS, Linux, and Windows, a web interface, and mobile apps for both iOS and Android. Both mobile apps are free and published by Block, Inc.

The desktop application connects with locally installed agent harnesses such as goose, Claude Code, and Codex. These harnesses run independently on the user’s computer.

The mobile applications provide remote access to the Buzz workspace. Users can monitor conversations, interact with AI agents, and respond to requests while away from their computers.

How does Buzz differ from traditional project management tools?

Buzz combines real-time communication, AI agents, and project context into a single workspace, whereas traditional project management tools focus on task tracking, timelines, and resource allocation.

Buzz works best as a coordination and communication layer. It can complement dedicated project management tools rather than fully replace them.

Teams that need Gantt charts, resource planning, or granular task statuses will likely retain a dedicated project management tool. They can use Buzz alongside it for communication, project context, and AI-assisted coordination.

How to get started with Buzz

To get started with Buzz, first set up a running workspace, either through Block’s hosted service or by self-hosting.

For teams choosing the self-hosted route, setting up Buzz on your own server involves configuring several services, including the relay, database, caching layer, and media storage. Managing these services manually adds operational overhead.

If you want self-hosted control without the setup overhead, a preconfigured deployment can handle the heavy lifting. That way, your team spends time on the use cases above rather than on infrastructure.

Hostinger offers a one-click Buzz deployment starting at $6.49/month for 24 months. It runs on Docker and automatically provisions the relay, database, caching layer, and media storage. After choosing a VPS plan and launching the deployment, you’ll have a Buzz instance ready for your team.

All of the tutorial content on this website is subject to

Hostinger’s rigorous editorial standards and values.

The author

Justina Bogužaitė

Justina is a Content Writer passionate about marketing, with a background in social media and customer success management. She also loves reading books, traveling and exploring new places as well as cooking, and trying out new recipes. Follow her on LinkedIn.

The post 7 Buzz use cases for development and project teams appeared first on WEBNET Hosting.

Most Linux interview lists recycle the same 10 questions from a decade ago, and many of the “official” answers are outdated or no longer apply to modern Linux distributions.

While the fundamentals haven’t changed, Linux itself has evolved. Tools like journalctl have replaced older logging methods on many distributions, ss has largely replaced netstat, and several traditional services and commands are no longer the default.

If you’re preparing for a Linux System Administrator, DevOps, or Site Reliability Engineer (SRE) interview, simply memorizing answers isn’t enough.

Interviewers often ask follow-up questions to see whether you truly understand the concepts and can solve real-world problems. Being able to explain why something works and demonstrate it with the correct Linux command can make all the difference.

We originally published this interview guide several years ago, but it was due for an update. Some of the services mentioned in the original version are no longer used on modern Linux distributions, and one of the answers was technically incorrect.

We’ve completely revised the guide to reflect today’s Linux environments, replacing outdated information with practical, accurate explanations and the commands you’ll actually use as a Linux administrator.

Whether you’re preparing for your first Linux interview or brushing up on your skills before your next role, these 15 interview questions will help you build the confidence to answer beyond textbook definitions and demonstrate real hands-on Linux knowledge.

1. How do you Suspend a Running Process and Move it to the Background?

Press Ctrl+Z while a process is running in the foreground. This sends the SIGTSTP (Terminal Stop) signal, which pauses the process without terminating it and returns you to the shell prompt.

Once the process is suspended, you can manage it using the following job control commands:

• bg – Resumes the suspended job in the background, allowing it to continue running while you use the same terminal.
• fg – Brings a background or suspended job back to the foreground.
• jobs – Lists all jobs running or suspended in the current shell session, along with their job numbers (such as %1, %2, and so on).

For example, suppose you start a large rsync backup and then realize you need the terminal for another task. Instead of stopping the transfer and starting over, press Ctrl+Z to suspend it, run bg to continue it in the background, and keep working in the same terminal.

If you later need to interact with the process again, use fg %1 (replace %1 with the appropriate job number) to bring it back to the foreground.

$ rsync -av /home/user/Documents/ /backup/ 
^Z [1]+ Stopped rsync -av /home/user/Documents/ /backup/ 
$ bg [1]+ rsync -av /home/user/Documents/ /backup/ & 
$ jobs [1]+ Running rsync -av /home/user/Documents/ /backup/ & 
$ fg %1 rsync -av /home/user/Documents/ /backup/

2. What’s the Minimum Partition Setup to Install Linux, and How do You Check boot Messages?

The minimum partition required to install Linux is a single root (/) partition. The system can boot and run with just this partition.

However, most production systems use a few additional partitions or volumes:

• / (root) – Stores the operating system and applications.
• /boot – Contains the kernel and bootloader files. This is often kept separate, especially on systems that use full-disk encryption.
• Swap – Provides virtual memory when RAM is low and is also used for hibernation. Modern systems typically don’t need the old “swap = 2× RAM” rule. A small swap partition or swap file is enough for most workloads.

To troubleshoot boot problems or review what happened during startup, you can use these commands:

• dmesg – Displays kernel boot messages and the kernel ring buffer. It’s useful for checking hardware detection, driver loading, and kernel-related errors.
• journalctl -b – Shows the complete log for the current boot on systemd-based distributions such as Ubuntu, RHEL, Fedora, Debian, and Rocky Linux.
• journalctl -b -p err – Displays only error messages from the current boot, making it easier to spot problems.

For example:

$ dmesg | less

$ journalctl -b

$ journalctl -b -p err

On older Linux distributions that used the SysV init system, boot logs were commonly stored in files such as /var/log/boot.log. On modern Linux distributions that use systemd, however, journalctl is the primary tool for viewing boot logs and troubleshooting startup issues.

3. Which Daemon Tracks System Events on a Modern Linux System?

Years ago, the expected answer to this question was syslogd, because it was the standard system logging daemon on traditional Unix and Linux systems. While you may still hear it mentioned in interviews, most modern Linux distributions have moved to newer logging solutions.

Today, the logging system depends on the Linux distribution you’re using:

• Ubuntu and Debian – Use rsyslog by default, which stores logs as plain text files under directories such as /var/log/.
• RHEL, Rocky Linux, Fedora, and other systemd-based distributions – Use systemd-journald, which stores logs in a binary journal that you view using the journalctl command.

Knowing which logging system your distribution uses is important because the commands for viewing logs are different.

For example, to check SSH login activity:

# RHEL, Rocky Linux, Fedora
$ journalctl -u sshd

# Ubuntu and Debian
$ grep 'sshd' /var/log/auth.log

If you’re troubleshooting a service, you can also view its logs with:

$ journalctl -u nginx
$ journalctl -u sshd

Understanding the difference between rsyslog and systemd-journald shows that you’re familiar with how logging works on modern Linux systems, not just older distributions.

4. What do you need Before Running fsck on the root Partition?

Before running fsck on the root filesystem, it must not be mounted in read-write mode. Running fsck on an active, writable filesystem can lead to data corruption because the operating system may still be writing to the disk while the check is in progress.

The safest approaches are:

• Boot into rescue mode, single-user mode, or from a live Linux environment, and run fsck when the root filesystem is not in use.
• If the root filesystem is mounted, remount it as read-only before running fsck (when appropriate).
• If you can’t run fsck immediately, schedule a filesystem check for the next boot.

For example:

# Remount the root filesystem as read-only
$ mount -o remount,ro /

# Run a filesystem check (replace the device as needed)
$ fsck /dev/sda2

To force a filesystem check during the next boot:

# Older Linux systems
$ touch /forcefsck

On modern systemd-based distributions, you can also add the kernel boot parameter:

fsck.mode=force

This tells the system to perform a filesystem check during startup.

5. How do You Copy a Directory tree While Preserving its Structure?

A traditional Unix tool for copying an entire directory tree is cpio. It preserves the directory hierarchy and can also retain file permissions and timestamps.

Although it isn’t used as frequently today, it still appears in certification exams such as The LFCS Certification Preparation Course and in some Linux interviews.

A classic example is:

$ find /home -depth | cpio -pdm /backup

Here’s what each part does:

• find /home -depth – Lists all files and directories under /home, processing files before their parent directories.
• cpio -p – Uses pass-through mode to copy files directly to another directory.
• -d – Creates destination directories if they don’t already exist.
• -m – Preserves the original modification times.

Although cpio is still worth knowing for certifications and interviews, most Linux administrators now use rsync for this task because it’s simpler, faster, and can resume interrupted transfers.

For example:

$ rsync -a /home/ /backup/

The -a (archive) option preserves the directory structure, permissions, ownership, timestamps, symbolic links, and other important file attributes, making it the preferred choice for most real-world Linux systems.

6. How do You Automate Log Rotation?

The standard tool for automating log rotation on Linux is logrotate. It manages log files by rotating, compressing, removing, and recreating them based on rules you define. This prevents log files from growing indefinitely and consuming valuable disk space.

On most Linux distributions, including Ubuntu, Debian, RHEL, Rocky Linux, and Fedora, logrotate is installed by default and runs automatically through cron or a systemd timer.

Configuration files are stored in:

• /etc/logrotate.conf – The main configuration file.
• /etc/logrotate.d/ – Contains separate configuration files for individual services such as Apache, Nginx, MySQL, and others.

A typical logrotate configuration lets you control:

• How often logs are rotated (daily, weekly, monthly)
• How many old log files are retained
• Whether rotated logs are compressed
• Whether empty log files should be ignored
• Whether a service should be restarted after rotation

For example:

/var/log/myapp.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

This configuration rotates the log every week, keeps four archived copies, compresses old logs, ignores missing log files, and skips rotation if the log file is empty.

One important point worth mentioning in an interview is that systemd journal logs are not managed by logrotate. Instead, systemd-journald manages its own logs.

To reduce journal logs to a maximum size:

# Reduce journal size to 500 MB
$ journalctl --vacuum-size=500M

# To remove journal entries older than two weeks:
$ journalctl --vacuum-time=2weeks

Permanent journal storage limits are configured in:

/etc/systemd/journald.conf

For example, you can set options such as SystemMaxUse to limit how much disk space the journal is allowed to use.

7. How do You Find Out Who Scheduled a Job With at?

The at command schedules a one-time task to run at a specified date and time. To view pending jobs, use at -l or its equivalent atq.

at -l
or
atq

The output displays the job number, scheduled execution time, and the user who created the job.

Example:

3   Sat Aug  1 02:00:00 2026 a username

# To view the commands that a scheduled job will execute, use:
at -c 3

(Replace 3 with the appropriate job number.) If you no longer need a scheduled job, you can remove it with:

atrm 3
or
at -r 3

This command deletes the specified job from the queue. Interviewers often ask this question to test whether you understand the difference between at and cron.

• at is used for one-time scheduled tasks.
• cron is used for recurring tasks that run at regular intervals, such as every hour, every day, or every week.

For example, if you’re asked to schedule a one-time database backup at 2:00 AM tonight without modifying the system crontab, at is the correct tool.

8. How do You View the Contents of a Tar Archive Without Extracting it?

To list the contents of a tar archive without extracting any files, use the tar command with the -t (list) option.

tar -tvf backup.tar.gz

Here’s what each option does:

• -t – Lists the contents of the archive instead of extracting it.
• -v – Displays detailed (verbose) information, including file permissions, owner, group, size, and modification time.
• -f – Specifies the archive file to operate on.

A typical output looks like this:

-rw-r--r-- root/root      1024 2026-07-30 10:15 backup/file1.txt
drwxr-xr-x root/root         0 2026-07-30 10:15 backup/config/
-rw-r--r-- root/root      2048 2026-07-30 10:16 backup/config/app.conf

Listing an archive before extracting it is a good practice because it lets you verify the files it contains and their directory structure.

One useful detail is that modern GNU tar automatically detects common compression formats such as gzip (.tar.gz), bzip2 (.tar.bz2), and XZ (.tar.xz). This means you usually don’t need to specify options like -z, -j, or -J explicitly.

For example, these commands all work with modern GNU tar:

tar -tf backup.tar.gz
tar -tf backup.tar.bz2
tar -tf backup.tar.xz

Older versions of tar often required compression-specific options, which is why you’ll still see commands like tar -ztvf archive.tar.gz in older documentation.

9. What is a Page Fault, and When Does it Happen?

A page fault occurs when a running process tries to access a memory page that is not currently mapped into physical RAM. Contrary to a common misconception, page faults do not occur when a program exits, they happen while a program is actively running and requesting memory.

When a page fault occurs, the Linux kernel determines whether the required page can be mapped immediately or whether it must first be loaded from disk.

There are two types of page faults you should know:

• Minor page fault – The required page is already available in memory (for example, in the page cache or shared with another process). The kernel simply updates the page tables, so no disk I/O is required.
• Major page fault – The required page must be loaded from disk (such as from an executable file, a memory-mapped file, or swap). Because disk access is much slower than RAM, frequent major page faults can significantly reduce system performance.

You can monitor system-wide memory and swap activity with:

$ vmstat 1

Pay attention to the si (swap in) and so (swap out) columns. Consistent activity in these columns may indicate that the system is under memory pressure.

To view page fault statistics for a specific process, use:

$ ps -o min_flt,maj_flt -p 

Here:

• min_flt shows the number of minor page faults.
• maj_flt shows the number of major page faults.

A high number of major page faults often indicates that the system is running low on available memory and spending time reading pages from disk instead of RAM.

10. What are Return Codes, and How do you use Them?

A return code, also known as an exit status, is the value a program returns to the shell when it finishes executing. By convention:

• 0 indicates the command completed successfully.
• Any non-zero value indicates an error or abnormal condition. The exact meaning of the non-zero value depends on the program that generated it.

To check the exit status of the last command, use:

$ grep "error" logfile.txt
$ echo $?

If grep finds a match, echo $? returns 0. If no match is found, it returns a non-zero exit status.

Exit codes are especially useful in shell scripts, where you can control what happens next based on whether a command succeeds or fails.

For example:

# Run cmd2 only if cmd1 succeeds
$ cmd1 && cmd2

# Run cmd2 only if cmd1 fails
$ cmd1 || cmd2

This makes it easy to automate tasks and handle errors without writing complex logic.

11. What’s the Difference Between a Hard Link and a Symbolic Link?

Both hard links and symbolic (soft) links provide another way to access a file, but they work differently.

A hard link is another directory entry that points to the same inode as the original file. Since both names refer to the same data on disk, deleting the original filename does not remove the file as long as at least one hard link still exists.

A symbolic link (or symlink) is a special file that stores the path to another file or directory. If the original file is deleted or moved, the symlink becomes broken because its target no longer exists.

Create them using:

# Create a hard link
$ ln target_file hardlink

# Create a symbolic link
$ ln -s target_file symlink

There are a few important differences:

In practice, symbolic links are used far more often because they’re flexible and can point to files or directories anywhere on the system. Hard links are mainly used when multiple filenames need to reference the same underlying file without duplicating its data.

12. What’s the Difference Between kill -9 and kill -15?

The kill command sends signals to processes. The two signals most commonly discussed in interviews are SIGTERM (15) and SIGKILL (9).

• kill -15 sends SIGTERM, which politely asks a process to terminate. The process has a chance to close files, save data, release resources, and exit cleanly.
• kill -9 sends SIGKILL, which immediately stops the process. The process cannot catch or ignore this signal, so it has no opportunity to perform any cleanup.

In most cases, you should try SIGTERM first. In fact, if you don’t specify a signal, kill sends SIGTERM by default.

For example:

# Send SIGTERM (default)
$ kill 1234

# Equivalent to the above
$ kill -15 1234

# Forcefully terminate the process
$ kill -9 1234

Use SIGKILL only when a process is completely unresponsive and does not exit after receiving SIGTERM. Forcefully killing applications such as databases can interrupt ongoing operations and may leave data in an inconsistent state.

13. How do You Check Open Ports and Listening Services?

The recommended tool for viewing network connections on modern Linux systems is ss. It has replaced netstat on most distributions because it’s faster and reads socket information directly from the kernel.

To display all listening TCP and UDP ports along with the owning process, run:

$ ss -tulpn

The options mean:

• -t – Show TCP sockets.
• -u – Show UDP sockets.
• -l – Display only listening sockets.
• -p – Show the process name and PID using each socket.
• -n – Display numeric addresses and port numbers instead of resolving hostnames.

Example output:

Netid State  Recv-Q Send-Q Local Address:Port  Process
tcp   LISTEN 0      128    0.0.0.0:22         users:(("sshd",pid=892,fd=3))
tcp   LISTEN 0      511    0.0.0.0:80         users:(("nginx",pid=1215,fd=6))

If a service fails to start, one of the first things to check is whether another process is already using the required port.

For example:

# Check the service status
$ systemctl status nginx

# See if port 80 is already in use
$ ss -tulpn | grep :80

This quickly tells you whether the service is listening on the expected port or if another application has already claimed it.

14. What is the OOM Killer, and How Does it Decide What to Kill?

The Out-Of-Memory (OOM) killer is a Linux kernel feature that automatically terminates a process when the system runs out of available memory and cannot recover by using swap space. Its goal is to free memory and keep the system running instead of allowing it to become completely unresponsive.

The OOM killer does not choose a process at random. The kernel assigns each process an OOM score based on factors such as its memory usage and other criteria. Processes with a higher score are more likely to be terminated.

To view the OOM score of a process, run:

$ cat /proc//oom_score

You can also influence how likely a process is to be selected by adjusting its oom_score_adj value:

$ cat /proc//oom_score_adj

The value ranges from -1000 to 1000:

• -1000 – Prevents the process from being selected by the OOM killer.
• 0 – Uses the default behavior.
• 1000 – Makes the process much more likely to be terminated.

For example, to protect a critical process:

$ echo -1000 | sudo tee /proc//oom_score_adj

If a system is repeatedly invoking the OOM killer, it’s usually a sign that it needs more available memory, a larger swap space, or applications that use less memory.

15. How do You Find Files Modified in the Last 24 Hours?

To find files that were modified within the last 24 hours, use the find command with the -mtime option:

$ find /var/log -mtime -1

Here’s what it means:

• find /var/log – Searches for files under the /var/log directory.
• -mtime -1 – Finds files modified less than one day ago.

You can also search for other time ranges:

# Modified exactly one day ago
$ find /var/log -mtime 1

# Modified more than one day ago
$ find /var/log -mtime +1

If you need more precise control, use -mmin, which works in minutes instead of days.

For example, to find files modified within the last hour:

$ find /var/log -mmin -60

This command is especially useful when troubleshooting issues. If a service suddenly stops working, you can quickly identify log files, configuration files, or other files that were recently modified and investigate what changed before the problem occurred.

Conclusion

Linux interview questions are designed to test more than your ability to memorize commands. Interviewers want to know whether you understand how Linux works, can explain key concepts clearly, and know which commands to use when troubleshooting real systems.

The 15 questions in this guide cover topics you’ll encounter in many Linux system administrator, DevOps, and cloud engineering interviews.

Spend some time practicing each command on a Linux machine, experiment with different options, and try to understand the output instead of simply memorizing it. That hands-on experience will make it much easier to answer follow-up questions with confidence.

If you’re preparing for Linux interviews, keep this guide as a quick reference and revisit these concepts regularly. A solid understanding of the basics is often what sets successful candidates apart.

The post 15 Linux Interview Questions and Answers for System Administrators appeared first on WEBNET Hosting.

The post The Tech House Needs a Workshop… appeared first on WEBNET Hosting.

If you’ve ever struggled to scale MySQL beyond a single write node, TiDB offers a solution without requiring you to learn a new query language. It uses the MySQL protocol, so your existing applications, drivers, ORMs, and even the mysql client work with it. Let’s get TiDB up and running.

What Is TiDB

TiDB is an open-source distributed SQL database developed by PingCAP. It separates computing and storage into different components:

• TiDB handles SQL queries and client connections.
• TiKV stores the data.
• PD (Placement Driver) manages the cluster and keeps everything working together.

Because these components run independently, you can scale storage or computing resources separately instead of upgrading a single server. This makes TiDB a good choice for applications that need to handle large amounts of data and growing workloads.

As a MySQL database grows, a single server can eventually become a bottleneck. TiDB solves this by distributing data across multiple nodes while remaining compatible with MySQL.

This means you can continue using familiar SQL syntax, existing MySQL clients, drivers, and applications without learning a new query language or rewriting your code.

This tutorial was tested on Ubuntu 26.04 LTS and Rocky Linux 9.5, but the same steps work on most modern 64-bit Linux distributions. TiDB 8.5.7 is the current stable release at the time of writing.

Before you begin, note that TiDB 8.4 and later no longer support RHEL 7. If you’re still using either of those operating systems, you’ll need to upgrade to a supported release, such as Rocky Linux 9.1 or later, before installing TiDB.

Step 1: Install TiUP, the TiDB Package Manager

Before you can install or deploy TiDB, you first need TiUP, the official package manager for the TiDB ecosystem. TiUP simplifies the installation process by downloading and managing the required TiDB components whenever you create or deploy a cluster.

This means you don’t have to download or configure TiDB, TiKV, PD, or other components manually.

To install TiUP, run the following command on Ubuntu, Debian, RHEL, Rocky Linux, or any other supported 64-bit Linux distribution:

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

Here’s what this command does:

• curl downloads the installation script from PingCAP’s server.
• --proto '=https' allows only HTTPS connections, preventing insecure HTTP downloads.
• --tlsv1.2 requires TLS 1.2 or a newer version for a secure connection.
• -sSf runs curl quietly, but still displays errors and stops if the download fails.
• | sh sends the downloaded script directly to the shell for execution.

When the installation finishes, the tiup command is installed in the ~/.tiup/bin directory. Now reload your shell configuration so the tiup command is available in the current terminal session:

source ~/.bashrc

If you’re using Zsh, reload its configuration instead:

source ~/.zshrc

To confirm that TiUP was installed successfully, check its version:

tiup --version

You should see output similar to this:

tiup version 1.x.x

If you get a tiup: command not found error, make sure ~/.tiup/bin has been added to your shell’s PATH. The installer normally updates ~/.bashrc automatically, but if you’re using another shell such as Zsh, you may need to add it to your shell configuration file manually.

Step 2: Start a Local TiDB Cluster

With TiUP installed, you can start a local TiDB cluster using the playground component. It automatically launches all the core TiDB services, including TiDB, TiKV, PD, and TiFlash, making it the quickest way to try TiDB on your own machine.

Start the playground cluster by running:

tiup playground

The first time you run this command, TiUP downloads all the required components, so it may take a few minutes depending on your internet connection.

Once the cluster starts successfully, you’ll see output similar to this:

🎉 TiDB Playground Cluster is started, enjoy!

Connect TiDB:    mysql --comments --host 127.0.0.1 --port 4000 -u root
TiDB Dashboard:  http://127.0.0.1:2379/dashboard
Grafana:         http://127.0.0.1:3000

The important detail here is that TiDB listens on port 4000 by default, not the standard MySQL port 3306. If you try connecting with a MySQL client configured for port 3306, the connection will fail.

By default, the playground cluster listens only on 127.0.0.1, which means it accepts connections only from the local machine. If you’re running TiDB on a remote server and want to connect from another computer, start it with:

tiup playground --host 0.0.0.0

If you do this, make sure your server’s firewall allows access to port 4000 from the systems that need to connect.

Step 3: Connect to TiDB with the MySQL Client

Since TiDB is compatible with the MySQL protocol, you can connect to it using the standard MySQL client. There’s no need to install a separate client.

If you don’t already have the MySQL client installed, install it first.

On Ubuntu or Debian, run:

sudo apt install mysql-client -y

On RHEL or Rocky Linux, run:

sudo dnf install mysql -y

The sudo command runs the installation with administrator privileges, which are required to install system packages. Without it, the installation will fail due to insufficient permissions.

Once the MySQL client is installed, connect to your running TiDB playground cluster:

mysql --host 127.0.0.1 --port 4000 -u root

If the connection is successful, you’ll see the MySQL prompt:

Welcome to the MySQL monitor...

mysql>

Notice that you’re connecting to port 4000, which is TiDB’s default SQL port.

The local playground cluster does not require a password for the root user, so you’ll be logged in immediately. This is normal for a local test environment and is meant to make learning and development easier.

In a production deployment, you should always secure the root account and configure proper authentication before allowing users to connect.

Step 4: Run Your First Queries

Now let’s create a database, add a table, insert some data, and verify that everything is working correctly.

At the mysql> prompt, run the following SQL commands:

CREATE DATABASE tecmintdb;

USE tecmintdb;

CREATE TABLE servers (
    id INT PRIMARY KEY,
    hostname VARCHAR(50),
    role VARCHAR(20)
);

INSERT INTO servers VALUES
    (1, 'web01', 'frontend'),
    (2, 'db01', 'backend');

SELECT * FROM servers;

If everything is working correctly, you’ll see output similar to this:

+----+----------+----------+
| id | hostname | role     |
+----+----------+----------+
|  1 | web01    | frontend |
|  2 | db01     | backend  |
+----+----------+----------+
2 rows in set

As you can see, working with TiDB feels just like working with MySQL. You use the same SQL statements to create databases and tables, insert data, and query records. Existing MySQL knowledge and tools work without any changes, making it easy to get started with TiDB.

If you already know MySQL, getting started with TiDB feels familiar. If you need a refresher on the basics, check out TecMint’s guide on creating and managing MySQL databases and tables.

Deploying TiDB Beyond a Local Playground

The tiup playground cluster is designed for learning and testing. It starts a temporary TiDB cluster that runs in the foreground. When you stop it, the cluster and its data are removed unless you start it with a --tag option to preserve the data.

For development, testing, or production environments, you should deploy a real TiDB cluster using tiup cluster deploy. This deployment method uses a topology YAML file to define which servers will run the TiDB, TiKV, and PD components. TiUP then connects to those servers over SSH and installs the cluster automatically.

If you’re deploying TiDB on a server that accepts remote connections, make sure the SQL port (4000) is allowed through the firewall.

On Ubuntu or Debian systems using UFW, run:

sudo ufw allow 4000/tcp

On RHEL or Rocky Linux systems using firewalld, run:

sudo firewall-cmd --permanent --add-port=4000/tcp
sudo firewall-cmd --reload

After the firewall is configured, remote clients can connect to TiDB on port 4000, provided the server is configured to accept external connections.

If you’re new to firewalld, check out our guide on how to configure firewalld in Linux to learn about firewall zones and creating permanent rules.

Once TiDB is deployed as a production cluster, you’ll manage its services just like any other systemd service. See our systemctl command guide to learn how to start, stop, restart, and enable services at boot.

Common Errors to Watch For

If you run into problems while setting up TiDB, here are the most common ones and how to fix them.

Connection refused on port 3306

If your MySQL client reports a connection error on port 3306, you’re probably trying to connect to the default MySQL port.

The TiDB playground listens on port 4000 by default, so connect using:

mysql --host 127.0.0.1 --port 4000 -u root

Permission denied during installation

If you see a Permission denied error while installing the MySQL client, the package manager wasn’t run with administrator privileges.

Run the installation command with sudo:

sudo apt install mysql-client -y

or on RHEL-based systems:

sudo dnf install mysql -y

If the tiup command isn’t found after installation, your shell hasn’t picked up the updated PATH yet.

Reload your shell configuration:

source ~/.bashrc

If you’re using Zsh, run:

source ~/.zshrc

If the problem persists, verify that the ~/.tiup/bin directory has been added to your shell’s PATH environment variable. Opening a new terminal session also reloads the updated environment automatically.

Conclusion

You have successfully installed TiUP, started a local TiDB cluster, connected to it using the standard MySQL client, and run your first SQL queries. Since TiDB is compatible with the MySQL protocol, you can use the same SQL syntax and many of the same tools you’re already familiar with, making it easy to get started.

Once you’re comfortable with the playground environment, try starting a larger local cluster to see how TiDB’s distributed architecture works:

The post TiDB: Build a MySQL-Compatible Distributed SQL Database on Linux appeared first on WEBNET Hosting.