C

Cloudlinux

Linux-based hosting OS with resource isolation

Head of Direct Sales

Full-TimeUpdated on 10/17/2026
No salary listed
Expert
Seattle, WA, USA
Remote
Sales & Account ManagementAccount Executive, Account Management

About the job

Requirements
  • Proven experience leading direct sales teams across North America and EMEA, with a strong record of achieving revenue targets.
  • Direct sales or sales leadership experience in software supply chain security, software composition analysis (SCA), application security, or DevSecOps is required; candidates must have sold enterprise solutions in this sector, and experience selling general IT or infrastructure software alone does not meet this requirement.
  • Hands-on experience selling solutions to buyers concerned with software vulnerabilities, end-of-life systems, compliance, or open-source security.
  • Strong deal-coaching and value-selling skills, including experience with tailored product packaging and dynamic pricing.
  • Ability to turn technical challenges into a clear business case for technical and executive stakeholders.
  • Experience managing new customer acquisition, account growth, and renewal motions.
  • Strong forecasting, pipeline management, negotiation, and presentation skills.
  • A coaching style that combines support, clear expectations, and accountability.
  • Familiarity with MEDDPICC or a comparable enterprise sales qualification methodology.
  • Willingness to travel as needed.
Responsibilities
  • Set and execute the direct sales strategy across North America and EMEA, turning revenue goals and territory plans into clear priorities for the team.
  • Lead, coach, and develop Enterprise Account Executives, Account Executives, account management, renewals, and sales development team members.
  • Work closely with sales representatives on active deals, helping them uncover customer needs, communicate business value, and develop effective proposals.
  • Support complex and strategic opportunities, including customer conversations, negotiations, and requests for tailored packaging or terms.
  • Drive performance across new business, account growth, and renewals while maintaining a healthy pipeline and accurate forecasts.
  • Review sales results and win/loss trends to identify coaching opportunities and improve the team’s approach.
  • Build strong relationships with strategic customers and identify opportunities to grow TuxCare’s presence in both regions.
  • Partner with Marketing, Revenue Operations, Product, and Finance to improve go-to-market execution and resolve customer needs.
  • Hire, onboard, and develop sales talent across North America and EMEA.
  • Represent TuxCare at relevant industry events and provide regular performance and forecast updates to the CRO and executive team.

About the company

C

Cloudlinux

View
Website

CloudLinux offers a Linux-based operating system designed for shared hosting providers and data centers. It runs on servers used by many customers and uses resource isolation to keep tenants from impacting each other. The core technology, Lightweight Virtual Environment (LVE), lets admins set per-user limits on CPU, memory, and I/O so a busy account won’t slow down others. Additional components include CageFS (a per-user virtualized file system for security), and PHP Selector (allows end-users to pick a PHP version). The company also markets Imunify360 for security and TuxCare for enterprise live patching. In 2021, CloudLinux started AlmaLinux OS as a free, community-driven Linux distribution to replace CentOS. The main goal is to help hosting providers run more customers per server, improve stability, and enhance security, thereby increasing profitability. CloudLinux serves thousands of hosting companies and millions of websites on hundreds of thousands of servers worldwide.

Company Size

201-500

Company Stage

N/A

Total Funding

N/A

Headquarters

Princeton, New Jersey

Founded

2009

Get referred to Cloudlinux

See people who can refer or advise you

Simplify Jobs

Simplify's Take

What believers are saying

  • March 24, 2026, MAx Cache became generally available for Apache and Nginx.
  • June 18, 2026, CloudLinux launched MariaDB 10.6 ELS for hosting customers.
  • Revelio counted 350 employees in March 2026, with 125 postings in 2026.

What critics are saying

  • Seahawk sued CloudLinux in Delaware on May 18, 2026 over AutopilotWP.
  • A May 22, 2026 restraining order blocked AutopilotWP before preliminary injunction review.
  • A lost Seahawk case or injunction blocks AutopilotWP and chills partner-sourced growth.

What makes Cloudlinux unique

  • CloudLinux sells hosting-specific Linux, isolating tenants with LVE, CageFS, and per-user limits.
  • TuxCare livepatching and ELS extend support across end-of-life kernels, databases, and runtimes.
  • AlmaLinux and MAx Cache deepen its control over host infrastructure and WordPress performance.

Help us improve and share your feedback! Did you find this helpful?

Benefits

  • Health Insurance
  • Paid Vacation
  • Paid Holidays
  • Paid Sick Leave
  • Remote Work Options
  • Flexible Work Hours
  • Gym Membership
  • Professional Development Budget
  • Conference Attendance Budget

Growth & Insights and Company News

Headcount

6 month growth

28%

1 year growth

28%

2 year growth

28%
Atlas Digital Summit
Sep 17th, 2026
Spotlight: Sergei Gruntovskii on securing AI Agents at Atlas Digital Summit 2026.

Spotlight: Sergei Gruntovskii on securing AI Agents at Atlas Digital Summit 2026. ATLAS Digital Summit is delighted to announce Sergei Gruntovskii, Chief Architect at CloudLinux, will be leading a critical discussion at the Atlas Digital Summit 2026 in Reykjavik, Iceland. As a distinguished expert at the forefront of server automation and security, Sergei brings an invaluable perspective to its invite-only C-level conference. Pioneering secure infrastructure. Sergei Gruntovskii's work at CloudLinux defines the technical direction for Linux platform security and server automation, impacting hosting providers globally. His deep understanding of kernel-level engineering, workload isolation, and managing vast operational fleets makes him uniquely qualified to address the complex challenges facing the industry today. The Atlas Digital Summit is dedicated to exploring the future of hosting, data centers, AI infrastructure, and security. Sergei's involvement underscores its commitment to featuring leaders who are actively shaping these domains with tangible, impactful solutions. Sergei Gruntovskii will lead the Security Track roundtable, focusing on the paramount challenge of 'Securing AI Agents Across the Hosting Fleet.' This session promises to delve into actionable strategies and advanced methodologies for protecting the integrity and performance of AI infrastructure at scale. This is a timely and crucial topic for all executives grappling with the rapid integration of AI into their operations. Attendees will gain direct insights from a technologist who navigates the intricacies of security and performance at the most fundamental levels. Join ATLAS Digital Summit to engage with Sergei Gruntovskii and other industry luminaries on September 28-29, 2026, for an unparalleled networking and knowledge-sharing experience.

CloudLinux
Jun 18th, 2026
MariaDB 10.6 reaches end of life on July 6. Here's how to keep your servers patched.

MariaDB 10.6 reaches end of life on July 6. Here's how to keep your servers patched. Jun 18, 2026 8:16:39 AM If you run MariaDB on your hosting servers, there's a date worth putting on the calendar: July 6, 2026. That's when MariaDB Community Server 10.6 reaches end of life. After that, the MariaDB project stops shipping releases, bug fixes, and security patches for the 10.6 branch. Today CloudLinux Inc. is announcing ELS for MariaDB, available now to CloudLinux customers. It keeps MariaDB 10.6 patched past its end of life, delivered as drop-in updates through the package manager you already use, so you can stay secure without forcing a database migration across your customers' sites. ELS for MariaDB is built and maintained by TuxCare, its sister company and the team behind KernelCare and the Endless Lifecycle Support program. What end of life actually changes On July 7, your databases will keep serving queries exactly as they did the day before. Nothing breaks at midnight. The problem is slower and more dangerous than that, and it compounds over the months that follow. Security patches stop. After July 6, vulnerabilities in MariaDB get fixed only in supported branches. The 10.6 branch goes quiet. When a project patches a supported version, the fix is public, so attackers can study exactly what changed and work out the underlying bug, then hunt for that same flaw in the versions that will never be patched. A database engine is a high-value target: it holds the data and it's reachable from your application servers. On a shared hosting environment, an unpatched database doesn't put one site at risk. It exposes every customer site that depends on it. Compliance risk rises. Most security frameworks expect known vulnerabilities to be patched on a schedule. PCI DSS Requirement 6 calls for critical and high-severity patches within a month of release. SOC 2, HIPAA, and FedRAMP all expect timely, documented patching. An unsupported database can be the single finding that holds up an otherwise clean audit, and cyber-insurance reviews increasingly check for unsupported software too. The ecosystem drifts away. Once a version reaches end of life, the software around it gradually stops supporting it. Distributions, container images, and third-party repositories move their defaults to newer releases. Six months in, the upgrade you were putting off has quietly gotten harder, not easier. Why "just upgrade" is rarely simple for a host Upgrading to a supported release like 11.4 is the right long-term move, and CloudLinux Inc.'ll always tell you that. But on a fleet of hosting servers, a major database upgrade is a real project, not a one-line command. The engine itself rarely slows you down. What slows you down is everything that assumes the behavior of your current version: customer applications, stored procedures, replication topologies, connector versions, and the surrounding tooling. MariaDB 11.0 even introduced a new optimizer cost model, so some queries can get slower until you tune them. Multiply that testing across thousands of customer databases and a fixed deadline, and the math gets uncomfortable. Rushed upgrades are expensive in a specific way: they ship bugs, and on a hosting platform those bugs land on customer sites that were running fine for years. That shows up the next quarter as support tickets, refunds, and churn. For some servers, a major upgrade this year isn't even worth it: a database behind an application that's being replaced, or one running a fixed workload, may not justify the disruption. The point isn't that you shouldn't upgrade. It's that the upgrade should happen on a timeline you control, driven by engineering reality rather than a calendar date set by someone else. How ELS for MariaDB works ELS for MariaDB decouples security from the upgrade deadline. Here's the mechanism: * TuxCare tracks the CVEs. As new vulnerabilities are disclosed in MariaDB 10.6 and the system libraries it depends on, TuxCare backports the fixes to your open-source release. * Patches arrive as drop-in package replacements. The patched build is the same MariaDB 10.6 version, signed and published to an ELS repository. Your yum or dnf pulls it like any other update. The engine stays 10.6; only the binaries get the fix. * Your data and workflows stay untouched. No schema changes, no application rewrites, no disruption to replication or backup tooling. This is a binary swap of the same version, not a data migration. * Coverage goes beyond the engine. ELS patches MariaDB's dependency graph too: storage engines, system libraries, and crypto components, rebuilt alongside the core. What this means depending on where you run MariaDB 10.6 ELS for MariaDB covers MariaDB 10.6 (x86_64) on CloudLinux 7, 8, and 9, as well as other EL 7/8/9 systems like CentOS and Oracle Linux. Other distributions are available on request. A few specifics: On CloudLinux 8 and 9: MariaDB 10.6 loses upstream security patches on July 6 regardless of your OS support status. To keep those servers patched, you'll want ELS for MariaDB. On CloudLinux 7: if you're already on CloudLinux 7 ELS and you installed MariaDB from the CloudLinux ELS repo, those packages are already on the patched update path. If you installed MariaDB from a third-party repository, the cleanest way onto coverage is to repoint to its repo so your package manager can pull the patched builds. Not sure where your packages came from? CloudLinux Inc. can help check. Anywhere else: if you run MariaDB 10.6 on other Linux distributions, ELS for MariaDB can still keep them secure. Talk to CloudLinux Inc. and CloudLinux Inc.'ll scope it. The approach CloudLinux Inc.'d actually recommend Run ELS and your upgrade together. Use ELS to take the deadline off the table, then plan and test your move to a newer LTS release properly. In most environments, a year of coverage costs far less than the incidents, downtime, and emergency work a rushed migration creates. July 6 is close. The good news is that getting covered is quick and changes nothing about how your databases run. Existing CloudLinux customer? Enable ELS for MariaDB in the CloudLinux Network portal. Running MariaDB somewhere else, or not sure what you need? Talk to its team and CloudLinux Inc.'ll figure out coverage for your environment. ELS for MariaDB is part of CloudLinux's Endless Lifecycle Support program, in partnership with TuxCare.

CloudLinux
May 1st, 2026
An update on CloudLinux's partnership with Seahawk.

An update on CloudLinux's partnership with Seahawk. May 1, 2026 8:42:30 AM CloudLinux OS team CloudLinux Inc. want to give its community an update: CloudLinux has ended its business relationship with Seahawk Global, LLC / Seahawk Media LLC. The termination of the business relationship is not a reflection of the service they provide. In November 2025, CloudLinux Inc. announced an investment in Seahawk to help its hosting partners offer white-label WordPress services. That partnership is now terminated, and as of today, CloudLinux has no business relationship with Seahawk. If you were introduced to Seahawk through CloudLinux, your agreement remains directly between you and Seahawk. If you have questions about this notice, reach out to CloudLinux Inc. directly at [email protected]. The CloudLinux Team

CloudLinux
Mar 19th, 2026
Introducing .htaccess Caching in MAx Cache: 20% faster Apache page loads.

Introducing .htaccess Caching in MAx Cache: 20% faster Apache page loads. Mar 19, 2026 4:15:29 PM Director of CloudLinux OS department Hosting servers with Apache can now handle 18% more traffic with 20% faster response times, without any configuration changes. Today CloudLinux Inc. is announcing the beta release of .htaccess cache, a new feature in MAx Cache that compiles .htaccess files into memory, eliminating the per-request disk I/O that slows down every page load on a server. This new feature builds on the MAx Cache for Apache module CloudLinux Inc. released in December 2025 and the MAx Cache for Nginx module that followed in early 2026. If you already run MAx Cache for Apache, you get .htaccess caching with a single package update. No new packages, no new configuration. This release also adds CloudLinux 10 support across the entire MAx Cache stack: Apache module, Nginx module, and .htaccess caching... Why .htaccess Files Are a Performance Problem On hosting servers with Apache, .htaccess files are everywhere. WordPress uses them for permalinks. AccelerateWP uses them for caching rules. Security plugins, control panels, and custom configurations all add their own directives. The problem is that Apache re-reads and re-parses these files on every single request. It walks the directory tree from top to bottom, opening each .htaccess along the way. A single page load can trigger half a dozen disk reads before Apache even begins serving content. Multiply that by every visitor, every page, every site on the server, and the overhead adds up fast. How .htaccess Caching Works It compiles .htaccess files once and keeps the result in memory. On subsequent requests, Apache applies the cached rules directly. No disk reads, no re-parsing. The cache fills itself automatically as traffic arrives. There is no startup cost and nothing to pre-configure. The first request to any path compiles its .htaccess chain into memory, and every request after that skips the disk entirely. Instant Change Detection Caching is only useful if changes still take effect immediately. The new feature includes a lightweight watcher daemon (htcache-watchd) that monitors the filesystem for .htaccess changes in real time. When a WordPress admin updates permalink settings or a control panel modifies access rules, the watcher picks up the change and signals Apache to recompile, typically within milliseconds. On CloudLinux 9 and 10, the watcher detects all types of changes: edits, deletes, renames, and moves. On CloudLinux 7 and 8, the watcher detects edits in real time, while a periodic fallback check catches deletes and renames (default: 60 seconds). Performance Gains CloudLinux Inc. benchmarked .htaccess caching on a 3,000-vhost server with 100 concurrent users, which is representative of a production shared-hosting environment. All tests ran over HTTPS with Apache Worker MPM. With a realistic workload (page + all assets) When each page load includes CSS, JS, and images (~78 static asset requests per page), .htaccess caching adds on top of MAx Cache page caching: * +18% requests per second (19,660 | 23,172 RPS) * 20% faster average TTFB (25.7 | 20.5 ms), 20% faster at p95 * 22% less CPU per request (39,332 | 30,568 μs) The gain is large because .htaccess elimination speeds up every request, both cached pages and static assets alike. With ~78 asset requests per page, the savings multiply across the entire page load. What .htaccess Caching Costs ~19 MB shared memory for 300 active domains (~65 KB per domain). Memory scales with active sites, not total configured sites. Inactive domains consume nothing. What This Means for Hosting Providers * Higher hosting density: 18% more throughput and 22% less CPU per request means more sites on the same hardware. The cost: ~65 KB shared memory per active domain. * Faster page loads: 20% lower TTFB translates directly into better user experience, even for requests that still go through PHP. * Zero configuration: .htaccess caching is on by default. The watcher starts automatically. Most servers need no tuning at all. Better Together: MAx Cache Page Caching + .htaccess Caching The MAx Cache page caching and .htaccess caching engines tackle different bottlenecks, and they stack: * .htaccess caching eliminates the disk I/O cost of reading .htaccess files on every request. * MAx Cache page cache eliminates PHP execution for cached WordPress pages. On a server running both, a request for a cached page never touches the disk for .htaccess and never invokes PHP. The entire response is served from memory. OS Support .htaccess caching supports CloudLinux 7, 8, 9, and 10. This release also brings full CloudLinux 10 support to both MAx Cache for Apache and MAx Cache for Nginx. How to Get Started The feature ships inside the ea-apache24-mod_maxcache package. If you already have MAx Cache for Apache, just update the package, and .htaccess caching enables itself automatically. New Installation * To install packages, run the following commands: yum install libmaxcache maxcache-htcache-watchd -enablerepo=cloudlinux-updates-testing yum install ea-apache24-mod_maxcache -enablerepo=cl-ea4-testing That's it. After installation: * The module loads into Apache automatically. * The filesystem watcher starts monitoring for .htaccess changes. * .htaccess caching is enabled by default. No additional steps required. For advanced configuration options, see the documentation. Looking for Feedback CloudLinux Inc. is eager to hear how .htaccess caching performs in your hosting environment. As this is a beta release, your feedback helps CloudLinux Inc. refine the feature before general availability. Please share your experience through the CloudLinux Feature Portal. Follow its blog for updates on its progress and the latest releases.

CloudLinux
Mar 4th, 2026
CloudLinux Is Heading to CloudFest 2026!

CloudLinux is heading to CloudFest 2026! Mar 4, 2026 1:36:02 PM Thando Sikhosana is a Marketing Coordinator within the Hosting Marketing team at CloudLinux. CloudFest 2026 is just around the corner, and the CloudLinux team is excited to once again join the global hosting community for one of the industry's most anticipated events. From 24 - 26 March 2026, CloudLinux will be attending CloudFest at Europa Park in Rust, Germany, connecting with hosting providers, infrastructure operators, and technology partners from across the world. If you are attending CloudFest this year, CloudLinux Inc. invite you to visit the CloudLinux team at Booth F02 to meet the team and learn what's next for CloudLinux OS and Imunify360. A Spotlight Session from CloudLinux CEO Igor Seletskiy One of the highlights for CloudLinux this year will be a main stage spotlight session presented by its CEO, Igor Seletskiy. Session Title More Revenue, Same Servers: What's Next from CloudLinux & Imunify Date and Time 24 March 2026 15:10 to 15:30 CET As hosting providers continue to navigate rising costs, competitive pricing pressures, and evolving customer expectations, unlocking more value from existing infrastructure has become increasingly important. In this 20 minute main stage session, Igor will share CloudLinux's perspective on how hosting providers can increase revenue potential while maintaining the stability and security their customers expect. The session will highlight the broader direction of the CloudLinux ecosystem, including developments across CloudLinux OS and Imunify, and how hosting companies can continue building sustainable, profitable platforms in a rapidly evolving hosting landscape. Attendees will also get a glimpse into what lies ahead for CloudLinux and how the company continues to support hosting providers as their infrastructure, security, and monetization strategies evolve. CloudLinux in the Modern Security Stack Tour CloudLinux will also participate in the Modern Security Stack Tour on Tuesday, 24 March. This guided tour brings together ecosystem partners covering different layers of the modern security stack, helping attendees understand how real world defence is built and integrated across cloud and hosted environments. During the tour, attendees will visit the CloudLinux booth to learn how CloudLinux OS and Imunify360 help hosting providers strengthen platform security while maintaining performance and stability. CloudLinux Tour Stop 24 March 15:03 to 15:08 The tour is designed for security leaders, infrastructure architects, and platform operators responsible for building layered and integrated defence across cloud and hosted environments. Meet the CloudLinux Team at Booth F02 Throughout the event, the CloudLinux team will be available at Booth F02 to discuss how its platform helps hosting providers deliver secure, stable, and profitable hosting environments. Whether you are looking to improve server stability, strengthen security, or unlock new monetization opportunities within your hosting stack, CloudLinux Inc. would be happy to connect and explore how CloudLinux can support your goals. Let's Connect at CloudFest If you are attending CloudFest 2026, stop by Booth F02 to meet the team and learn more about what's coming next for CloudLinux and Imunify. You can also reach out to schedule time with its sales team ahead of the event. | [email protected] CloudLinux Inc. look forward to seeing you in Rust!