oxpull.github.io/index.html at main · oxpull/oxpull.github.io · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Oxpull Pro waitlist. A production worker for Django Tasks</title>
  <meta name="description" content="A database-backed worker for Django's Tasks framework. Transactional enqueue, no broker. Join the waitlist for the Pro tier.">
  <link rel="canonical" href="https://oxpull.com/">

  <meta property="og:type" content="website">
  <meta property="og:site_name" content="Oxpull">
  <meta property="og:title" content="A production worker for Django Tasks">
  <meta property="og:description" content="A database-backed worker for Django's Tasks framework. Transactional enqueue, no broker. Join the waitlist for the Pro tier.">
  <meta property="og:url" content="https://oxpull.com/">
  <meta property="og:image" content="https://oxpull.com/assets/social-card.png">
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta property="og:image:alt" content="django-ox: Django 6 shipped Tasks, the production worker is missing.">
  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:title" content="A production worker for Django Tasks">
  <meta name="twitter:description" content="A database-backed worker for Django's Tasks framework. Transactional enqueue, no broker. Join the waitlist for the Pro tier.">
  <meta name="twitter:image" content="https://oxpull.com/assets/social-card.png">

  <link rel="stylesheet" href="style.css">
  <link rel="icon" href="assets/favicon.png">
  <link rel="apple-touch-icon" href="assets/favicon.png">
</head>
<body>
  <div class="wrap">

    <header class="top">
      <div class="wordmark"><span data-brand>Oxpull</span><span class="pro">Pro</span></div>
      <div class="top-note">waitlist</div>
    </header>

    <main>
      <section class="hero">
        <p class="eyebrow">django.tasks &middot; Django 6.0+</p>
        <h1>A production worker for Django Tasks</h1>
        <p class="lede">Django 6.0 ships the Tasks API, but its built-in backends are for
          development only. <strong><span data-brand>Oxpull</span></strong> stores the queue in the
          database you already run and executes tasks with a separate worker process. No broker,
          no Redis, nothing new to operate.</p>
        <p class="hero-sub">The part that matters: <code>enqueue()</code> is a plain INSERT on your
          default connection, so a task enqueued inside <code>transaction.atomic()</code> commits
          or rolls back together with your business data. A broker cannot share your database
          transaction. There is no window where an order exists without its email task, and no
          <code>on_commit</code> boilerplate.</p>

        <figure class="txn">
<pre><code><span class="dim">with</span> transaction.atomic():
<span class="atomic">    order = Order.objects.create(...)
    send_confirmation.enqueue(order.pk)</span>
<span class="dim"># one COMMIT. Both rows exist, or neither does.</span></code></pre>
          <figcaption>The task row and the order row share a transaction</figcaption>
        </figure>
      </section>

      <section class="bench">
        <h2>Measured, not promised</h2>
        <p>Against django-tasks-db 0.12 on PostgreSQL 16 (2,000 no-op tasks, three interleaved
          runs, one machine), <span data-package>django-ox</span> enqueued at 528 to 657 tasks
          per second versus 447 to 454, and completed the batch at 88 to 90 tasks per second
          versus 69 to 70 with a single worker. In-transaction enqueue latency was a tie, about
          half a millisecond at p50 for both.</p>
        <p>Reliability got the same treatment: 21 minutes of sustained load on PostgreSQL 16,
          37,802 tasks, including nine minutes in which workers were repeatedly SIGKILLed
          mid-task. Every task reached a terminal state, zero were lost, zero completed twice in
          that run, and interrupted work was reclaimed inside the documented bound.</p>
        <p class="caveat">No-op benchmarks flatter every queue, so read these as relative, not as
          capacity planning. The full methodology, every run, and the raw per-sample data ship in
          the repository.</p>
      </section>

      <section>
        <h2>Free core, paid scale</h2>
        <p>The open source worker is the production backend. Pro adds the features that only
          start to hurt once you have real volume.</p>

        <div class="tiers">
          <div class="tier">
            <h3><span data-package>django-ox</span> <span class="tag">BSD-3 &middot; free forever</span></h3>
            <ul>
              <li>Durable queue in your existing database</li>
              <li>Transactional enqueue</li>
              <li>At-least-once execution, SKIP LOCKED claiming</li>
              <li>Retries with backoff, per-attempt tracebacks</li>
              <li>Reaper for tasks from dead workers</li>
              <li>Graceful drain on SIGTERM</li>
              <li>Priorities, deferred tasks, multiple queues</li>
              <li>Recurring schedules, cron syntax</li>
              <li>Pruning command for finished rows</li>
              <li>Stats API and health command</li>
            </ul>
            <p class="note">PostgreSQL, SQLite and MySQL 8, all tested in CI. Live now:
              <code>pip install django-ox</code> &middot;
              <a href="https://github.com/oxpull/django-ox">GitHub</a> &middot;
              <a href="https://oxpull.com/django-ox/">docs</a>.</p>
          </div>
          <div class="tier pro-tier">
            <h3><span data-brand>Oxpull</span> Pro <span class="tag">commercial license</span></h3>
            <ul>
              <li>Batches: enqueue many, track as one</li>
              <li>Unique tasks (deduplication)</li>
              <li>Email support from the maintainer</li>
            </ul>
            <p class="note">Both built and tested. Not yet on sale: the purchase path is still
              being set up, and the waitlist below is how to hear when it opens. Delivered from a private
              package index using credentials issued per company, with no licence key and no runtime check
              to break your production. Install stays <code>pip install</code>.</p>
          </div>
        </div>
      </section>

      <section id="waitlist">
        <h2>Pricing, and the waitlist</h2>
        <p class="price-line">Pro launches at <strong>$399 per year, per company</strong>, flat,
          self-serve. The price moves toward $995 per year as the feature set fills out, so the
          waitlist is also the cheap seat: join now, buy at the launch price. Seven-day money-back,
          no trial keys.</p>

        <div class="signup">
          <form id="waitlist-form" method="post">
            <label for="email">Email address</label>
            <input type="email" id="email" name="email" required autocomplete="email"
              placeholder="you@company.com">
            <button type="submit">Join the waitlist</button>
          </form>
          <p id="form-error" hidden>That didn't go through. Check the address and try again.</p>
          <p class="privacy">Your email is used only to tell you when Pro launches. Reply
            "remove" and it is deleted.</p>
        </div>
      </section>

      <section class="faq">
        <h2>Questions you should ask</h2>

        <h3>What is the license situation?</h3>
        <p>The worker itself, <span data-package>django-ox</span>, is BSD 3-Clause and stays
          that way. Pro is separate code under a commercial license, sold per company. The free
          tier is not a demo; it is the backend the docs mean when they say production systems
          need a durable queue and a worker process.</p>

        <h3>When does this ship?</h3>
        <p>The open source worker is live: <code>pip install django-ox</code>, with
          <a href="https://oxpull.com/django-ox/">documentation here</a>. Pro is built and
          tested; what is left is the purchase path. Waitlist email is the announcement channel.</p>

        <h3>Who is behind it?</h3>
        <p>An independent software vendor with one product: this one. You will know who
          maintains it, contracts get signed under the company name, and support answers come
          from the person who wrote the code.</p>

        <h3>What does support look like?</h3>
        <p>Open source: GitHub issues, taken seriously. Pro: email support from
          the maintainer. If your procurement needs a PO and an invoice instead of a card,
          say so on the waitlist; invoiced purchasing is planned alongside self-serve.</p>

        <h3>Do I need Pro to run production?</h3>
        <p>No. Durability, retries, the reaper, and graceful shutdown are all in the free
          worker, and so are the stats API and the health command. Pro adds two
          things the free tier does not do: batching and deduplication. Support comes
          with it.</p>
      </section>
    </main>

    <footer>
      <p><span data-brand>Oxpull</span> is an independent vendor. Not affiliated with the Django
        Software Foundation.</p>
      <p>No analytics, no trackers, no cookies on this page. The only request that leaves it is
        the form you choose to submit.</p>
    </footer>

  </div>
  <script src="config.js"></script>
</body>
</html>