Coder Legion - Recent posts tagged directus

TanStack Start Basics Part 2 — Connecting to Your Directus Backend

Thu, 10 Sep 2026 22:12:24 +0000

Our frontend has been static so far — just hardcoded headings on a few pages. Today we connect it to the Directus backend built earlier in this series, using the official Directus SDK to pull real product data into our TanStack Start app.

Youtube Video - Tanstack Start Basics Part 2

Installing the Directus SDK

There are a few ways to talk to Directus from a frontend — the REST API directly, GraphQL — but the SDK is the cleanest option, and what we're using here.

npm install @directus/sdk

Creating the Directus Helper

Inside src/lib, create a new file: directus.ts.

import { createDirectus, rest } from '@directus/sdk'

export const directus = createDirectus('Your_Directus_Project_URL').with(rest())

createDirectus initializes a connection client between your app and your Directus instance. On its own it starts empty — capabilities get added by chaining .with(). Since we're fetching over standard HTTP REST requests, we pair it with the rest() modifier.

Defining Our First Type

Inside src, create types/index.ts:

export interface Products {
  id: string
  name: string
  brief: string
  description: string
  price: number
  sale: number
  quantity: number
  isOnSale: boolean
  category: string
  image: string
}

Writing the Fetch Function

Back in directus.ts:

import { createDirectus, rest, readItems } from '@directus/sdk'
import type { Products } from '@/types'

export const directus = createDirectus('Your_Directus_Project_URL').with(rest())

export async function getProducts(): Promise<Products[]> {
  return directus.request(
    readItems('products', {
      fields: [
        'id',
        'name',
        'brief',
        'description',
        'price',
        'sale',
        'quantity',
        'isOnSale',
        'category',
        'image',
      ],
    }),
  )
}

readItems is a built-in SDK helper that generates a request for fetching multiple items from a given collection. At this point, TypeScript throws:

Type 'Record<string, any>[]' is not assignable to type 'Products[]'.

Fixing the Schema Error

This happens because the SDK doesn't automatically know your database's actual shape — it needs a Schema type passed into createDirectus:

type Schema = {
  products: Products[]
}

export const directus = createDirectus<Schema>('Your_Directus_Project_URL').with(rest())

This declares that a products collection exists and maps to an array of Products. With this in place, the error resolves — and as a bonus, TypeScript now validates and autocompletes the fields array against this type too.

Fetching the Data — Method 1: TanStack Query

Install it:

npm i @tanstack/react-query

Set it up in __root.tsx:

import { QueryClient, QueryClientProvider } from '@tanstack/react-query'

// Create a client
const queryClient = new QueryClient()

function RootDocument({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <head>
        <HeadContent />
      </head>
      <body>
        <QueryClientProvider client={queryClient}>
          {children}
        </QueryClientProvider>
        <Scripts />
      </body>
    </html>
  )
}

Why does RootDocument take a children prop, and why wrap it? __root.tsx wraps your entire application — every route (About, Index, Products) gets passed in as children, rendered inside this HTML shell. Wrapping children with the query provider means every nested route and component now has access to TanStack Query.

Now build the component, src/components/Products.tsx:

import { useQuery } from '@tanstack/react-query'

export default function Products() {
  const { data: products, isLoading: loading } = useQuery({
    queryKey: ['product'],
    queryFn: getProducts,
    staleTime: 5 * 60 * 1000,
    gcTime: 15 * 60 * 1000,
    refetchOnWindowFocus: false,
    retry: 2,
    refetchOnMount: true,
  })

  if (loading) {
    return <div className="container mx-auto p-8">Loading...</div>
  }

  return (
    <div>
      <div className="container mx-auto p-8">
        <h1 className="text-4xl font-medium mb-4">Products</h1>
        <div className="grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 gap-6">
          {products?.map((product) => (
            <div key={product.id} className="border rounded-lg p-4">
              <h2 className="text-xl font-bold mb-2">{product.name}</h2>
            </div>
          ))}
        </div>
      </div>
    </div>
  )
}

A quick rundown of the query options:

Option	What it does
`staleTime`	How long fetched data stays "fresh" (5 min) before a refetch is considered
`gcTime`	How long unused data stays cached in memory (15 min) before being cleared
`refetchOnWindowFocus`	Whether switching tabs and back triggers a refetch (off here)
`retry`	Silent retry attempts on failure before giving up (2 here)
`refetchOnMount`	Whether the component checks for stale data and refetches on every mount (on here)

Wire it into the route:

import Products from '@/components/Products'
import { createFileRoute } from '@tanstack/react-router'

export const Route = createFileRoute('/products')({
  component: RouteComponent,
})

function RouteComponent() {
  return (
    <div className="p-8">
      <h1 className="font-bold text-5xl text-slate-700">Products</h1>
      <Products />
    </div>
  )
}

Visit localhost:3000/products — real product data, pulled live from Directus.

Fetching the Data — Method 2: Route Loaders

Loaders work a little differently, and only on routes directly — not on standalone components. Remove the Products component from the route and build it in directly:

import { createFileRoute } from '@tanstack/react-router'
import { getProducts } from '@/lib/directus'

export const Route = createFileRoute('/products')({
  loader: async () => {
    const products = await getProducts()
    return products
  },
  component: RouteComponent,
})

function RouteComponent() {
  const products = Route.useLoaderData()

  return (
    <div className="p-8">
      <h1 className="font-bold text-5xl text-slate-700 mb-4">Products</h1>
      <div className="grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 gap-6">
        {products?.map((product) => (
          <div key={product.id} className="border rounded-lg p-4">
            <h2 className="text-xl font-bold mb-2">{product.name}</h2>
          </div>
        ))}
      </div>
    </div>
  )
}

The loader runs getProducts before the route renders, and Route.useLoaderData() pulls that resolved data straight into the component — no loading state needed, since the data's already there by the time the page shows up.

Which One Should You Use?

Both approaches call the exact same getProducts function underneath — the difference is where the fetching happens and how the result reaches your component.

TanStack Query shines for data that changes often or benefits from caching, background refetching, and built-in loading states — great for a snappy feel on repeat visits.

Route loaders fetch before the route even renders, so there's no loading spinner at all. That pairs particularly well with TanStack Start's server-side rendering model, since the data can be resolved as part of the initial render rather than after the fact.

Summary

In this part, we:

Installed and configured the Directus SDK
Typed our data with a Products interface and a Schema
Built our first real fetch function using readItems
Rendered a live products grid two different ways — TanStack Query and a route loader

Right now we're only displaying each product's name, but this same pattern carries directly into fuller product cards next — pricing, images, sale badges, and eventually branding and tags once those relational fields come into play.

Found this useful? Follow for more Directus and TanStack Start tutorials, or check out the video version above.

Setting Up Our Frontend with TanStack Start

Tue, 08 Sep 2026 15:45:44 +0000

We've finished our backend series — a Directus instance running on a VPS managed by Coolify, backed by PostgreSQL and Redis, with a products collection already built and secured with roles and permissions.

Now it's time to build a frontend to actually display that data. For this, we're using TanStack Start, Tailwind CSS, and shadcn/ui. This post covers getting TanStack Start installed and running.

What Is TanStack Start?

Straight from the official docs:

TanStack Start is a full-stack React framework powered by TanStack Router. It provides full-document SSR, streaming, server functions, client/server builds, and more. With Vite and Rsbuild support, it's ready to develop and deploy to the hosting provider or runtime you want.

In short: it offers the same kind of full-stack capability as frameworks like Next.js or Remix, built on top of TanStack Router.

Creating the Project

First, create a folder for your app. I'm naming mine app_fe — "fe" for front end.

Naming convention tip: I use <app-name>_fe for all my frontend project folders — so an e-commerce project would be store_fe. Makes the folder's purpose obvious at a glance.

From inside that folder, run:

npx @tanstack/cli@latest create .

Note the trailing dot. Since we created the folder ourselves beforehand, the dot tells the CLI to install directly into the current directory. Omit the dot if you'd rather the CLI create a new folder for you.

Walking Through the Setup Prompts

The CLI will walk you through a series of choices:

Prompt	Selection
Select Framework	React
Select Toolchain	ESLint
Select Deployment Adapter	None (self-hosting on our own VPS)
Include demo/example pages?	No
What add-ons would you like?	shadcn/ui
Initialize a new git repository?	Yes
Continue with these settings?	Yes

Wait for the install to finish.

Running the App

Navigate into your app directory (if you aren't already there) and run:

npm run dev

Open your browser to http://localhost:3000. Congratulations — your TanStack Start app is up and running.

Editing the Home Page

Open src/routes/index.tsx. Delete everything inside the div, and save — your home page should now be completely blank. This file is your landing page, the first thing visitors see.

Add an h1 tag inside the empty div:

<h1>Home</h1>

Save, and you'll see "Home" rendered on the page. Now let's add some Tailwind styling:

<h1 className="font-bold text-5xl text-slate-700">Home</h1>

Save again — notice Tailwind works right out of the box, no extra configuration needed.

File-Based Routing

TanStack Start runs on TanStack Router, which uses file-based routing. Every file added to the routes folder automatically becomes a navigable page.

Adding an About Page

Create src/routes/about.tsx:

<div className="p-8">
  <h1 className="font-bold text-5xl text-slate-700">About</h1>
</div>

Save, then visit http://localhost:3000/about. Notice the home page lives at localhost:3000/, and the about page lives at localhost:3000/about — TanStack Start handled that routing automatically, purely based on the filename.

Adding a Products Page

Create src/routes/products.tsx the same way:

<div className="p-8">
  <h1 className="font-bold text-5xl text-slate-700">Products</h1>
</div>

Visit localhost:3000/products, and there's your new page. That's as simple as basic routing gets — there's plenty more you can do with nested and dynamic routes, which we'll cover as it becomes relevant.

What Is That `__root.tsx` File?

You've probably noticed a file called __root.tsx sitting in your routes folder. Here's the simplest way to think about it:

Picture any large website — Amazon, YouTube, anything. Every page has a header up top and often a footer at the bottom that never change, no matter what page you're on. But the content in the middle changes depending on where you navigated.

__root.tsx is the file that builds that "never changes" part. It's the frame around every page in your app. Every route you build — home, about, products — gets rendered inside this one file. Write it once, and every page automatically inherits it.

A word of caution: this file is central to how TanStack Router works under the hood. Avoid modifying it until you understand exactly what each piece does — we'll take a closer look at it in an upcoming post, exactly when it becomes relevant to what we're building.

Summary

In this part, we:

Installed and configured a new TanStack Start project
Ran it locally and confirmed Tailwind works out of the box
Learned file-based routing by building About and Products pages
Got introduced to __root.tsx, the file behind every page in the app

That wraps up our frontend setup. Next up, we'll start pulling real data from our Directus backend into this frontend — connecting everything we've built across this series.

Found this useful? Follow for more Directus and TanStack Start tutorials, or check out the video version above.

From Retrenchment to Full-Stack Developer: Wade Thomas on Learning, Simplicity and Building Software

Sat, 29 Aug 2026 09:12:49 +0000

From Retrenchment to Full-Stack Developer: Wade Thomas on Learning, Simplicity and Building Software That Matters

Developer Stories | CoderLegion

What happens when a career change forces you to rethink your future?

For Wade Alister Thomas, the answer was to turn a difficult setback into the beginning of a completely different career.

After spending 18 years working in the telecommunications industry, Wade was among approximately 500 employees who were retrenched in November 2018. He had recently started a family and finished building his home, so the timing could hardly have been more challenging.

At that point, Wade had a decision to make: look for another traditional job or take the small coding projects he had been doing on the side and turn them into a full-time career.

He chose the second path.

Today, Wade is a self-taught full-stack developer and consultant based in Trinidad & Tobago. His preferred stack includes TanStack Start, Tailwind CSS and shadcn/ui on the frontend, with Directus, PostgreSQL and Redis running on a VPS through Coolify.

He also works with businesses on their digital presence, builds applications, creates logos and Git templates, and regularly shares what he learns through technical articles.

In this Developer Stories interview, Wade talks about his journey from telecommunications to software development, the challenges of learning without a traditional curriculum, why he prefers simple and sustainable architectures, what attracted him to self-hosting, and why developers should focus on solving business problems rather than simply using the newest technology.

From 2014 to 2018: When a Career Changed Direction

Wade started coding in 2014, initially taking on small projects for friends and family.

At the time, however, software development was still something he was doing alongside his full-time career in telecommunications.

That changed in 2018.

About 500 employees at the telecommunications company were retrenched on November 15, 2018, and Wade was among them.

It was a particularly difficult period because he had recently started a family and had just finished building his home.

"It was a really difficult time, as I had started a family and just finished building our home."

After 18 years in telecommunications, Wade had to decide whether to look for another traditional job or pursue the coding work he had already started doing on the side.

With the support of his wife and after much prayer, he decided to pursue software development full-time.

That decision marked the beginning of a completely different professional journey.

The Challenge of Being a Self-Taught Developer

Being self-taught gave Wade freedom, but it also created one of the biggest challenges many independent developers face: deciding what to learn.

There was no university curriculum, mentor or structured program telling him which technology to choose next.

He initially enrolled with Treehouse but eventually had to stop because he could not afford the monthly subscription.

He began learning JavaScript, HTML and CSS, purchasing discounted courses on Udemy and experimenting with different technologies.

Eventually, he realized that knowing frontend technologies alone wasn't enough.

He needed to understand backend development as well.

The problem was that there was nobody to point him toward a specific path.

Before AI made technical research much easier, Wade had to search through the internet himself, experiment, make mistakes and figure things out through trial and error.

He eventually settled on React for the frontend and Node/Express for the backend.

But the experimentation didn't stop there.

He explored Vue.js, returned to React, and tried several frameworks including Next.js, Remix, Redwood and TanStack.

Then came another area of exploration: headless CMS platforms.

He experimented with Contentful, Strapi, DatoCMS, Sanity, Storyblok, Prismic, Payload and eventually Directus.

Looking back, Wade says deciding what to learn and sticking with it was a major struggle.

What eventually helped was finding a technology stack with a manageable learning curve and, more importantly, enjoying the process of learning.

The motivation shifted from simply trying to reach an outcome to genuinely enjoying the journey.

Finding a Stack That Works

Wade's current technology stack didn't appear overnight.

It evolved through real client work and the practical problems that came with building software as a solo developer.

His first paying client was a travel agency.

At the time, Wade was using React on the frontend and Node/Express on the backend.

That meant manually building many of the pieces required by the application, including forms, APIs and database functionality.

The workload was significant.

He didn't meet the original delivery date, although he ultimately delivered a working product.

That experience taught him something important about working as a solo developer: the technology stack itself can have a major impact on how quickly and sustainably you can deliver.

Instead of simply accepting the complexity, Wade began researching alternatives.

He wanted technologies that worked well together and allowed him to spend more time building the actual application instead of repeatedly wiring infrastructure together.

His current approach focuses on technologies including:

TanStack Start
Tailwind CSS
shadcn/ui
Directus
PostgreSQL
Redis
VPS infrastructure
Coolify

The goal isn't to use the most impressive stack possible.

It is to use a stack that works well for the types of clients he serves.

Because Wade primarily works with startups and small-to-medium businesses, he doesn't believe every project needs an enterprise-level architecture.

Instead, he looks for solutions that are affordable, sustainable and fast to deliver.

Why Wade Chose Self-Hosting

Many developers today immediately reach for managed platforms such as Vercel or Netlify.

Wade took a different route.

He initially used Netlify for some of his projects, but eventually became frustrated with aspects of the platform, including pricing, DNS management and deployment errors that weren't always intuitive.

The possibility of unpredictable hosting costs also made him cautious about some managed platforms.

Self-hosting offered a different model.

With a VPS and Coolify, Wade could control the hosting environment while still keeping much of the convenience developers expect from modern deployment platforms.

He could create subdomains, automatically manage SSL certificates, run frontend and backend applications on the same server, and deploy directly from GitHub.

For the types of businesses he works with, this provided a practical balance between flexibility, cost and simplicity.

But Wade sees another important benefit to self-hosting.

It forces developers to understand what actually happens when an application runs in production.

You have to understand the server, deployment process, database and infrastructure.

That knowledge can be valuable even when working with managed platforms.

For Wade, predictable costs are another major advantage.

Instead of worrying that an unexpected traffic spike or usage metric could suddenly increase a hosting bill, he knows what infrastructure he is paying for.

Self-hosting also reduces dependence on a particular provider's pricing and platform rules.

At the same time, Coolify provides many of the conveniences developers appreciate from managed platforms while allowing Wade to retain control over his infrastructure.

Why Directus Became an Important Part of His Stack

Before using Directus, Wade built backend systems using Node/Express.

That meant creating APIs, middleware, authentication and authorization himself.

For a solo developer, that can add a considerable amount of work to every project.

Directus changed that equation.

With Directus, Wade could quickly create a backend and automatically expose APIs through REST, GraphQL or the SDK.

The platform also provides a data studio that allows clients and non-developers to manage their own data.

Authentication is available out of the box, and Directus can connect to existing SQL databases.

For Wade, this makes Directus particularly useful for content-driven websites and fast-turnaround MVPs where speed and a client-friendly data management experience are important.

It also fits naturally into his self-hosting approach.

However, Wade doesn't see Directus as the answer to every backend problem.

For applications with highly complex business logic, he believes a custom backend can still be the better choice.

That distinction is important.

The goal isn't to find one technology that solves every problem.

The goal is to choose the right level of complexity for the problem being solved.

When Simplicity Becomes an Architecture Principle

One of the strongest themes in Wade's approach to development is simplicity.

Developers can easily become distracted by the desire to build something technically impressive.

Modern frameworks, animations, advanced architectures and new technologies can all be exciting.

But they can also distract from the actual purpose of a product.

Wade believes in launching a minimum viable product, keeping the initial implementation focused and adding complexity only when it becomes necessary.

Complexity has a cost.

It can increase:

Bugs
Development time
Testing requirements
Maintenance work
Project costs
Time required to get customer feedback

He experienced this mindset firsthand while building his own portfolio.

His initial idea was to create an impressive interactive website with transitions, parallax scrolling, dark mode, 3D images and animations.

Instead, he stepped back and asked what the portfolio actually needed to accomplish.

The purpose was simple: convince a potential client that he could build software that solved real-world problems.

So he created a much simpler interface and focused on examples of applications he had built.

The result was a faster launch and a clearer demonstration of his actual capabilities.

The lesson was simple:

A product doesn't need to demonstrate everything a developer knows. It needs to solve the problem it was created to solve.

From Developer to Consultant

Working directly with clients changed Wade's understanding of software development.

As a developer, it's easy to focus primarily on code.

But clients aren't usually buying code.

They're buying a solution to a business problem.

Wade learned that understanding the client's industry, customers and business goals is just as important as understanding the technology.

A web application is often not the business itself.

Instead, it becomes a tool that helps the business compete, communicate with customers or operate more effectively.

That means technology decisions should follow business requirements rather than dictate them.

Wade puts it simply:

"The technology must serve the solution, not the other way around."

This also means that the technically superior solution isn't always the right solution.

Sometimes the newest or most advanced technology is also the most expensive.

If that cost doesn't make sense for the business, Wade would rather recommend a proven and affordable solution.

The best architecture isn't necessarily the one with the most impressive technology.

Sometimes it is the one that makes the most sense for the business.

Building More Than Software

Wade's work extends beyond writing code.

He also works with UI/UX, ecommerce, performance, authentication, security, branding and logo design.

For him, understanding the user is a critical part of building software.

He gave the example of working with an ecommerce client selling natural self-care products.

Rather than immediately starting with the interface, Wade became a customer himself.

He bought and experienced the products, visited the client's pop-up events and observed the customers.

That helped him understand the product, the customers and the image the business wanted to communicate.

He could then use that understanding to shape the user interface and create a persona for the ideal customer.

This reinforced an important lesson:

A technically flawless application is not necessarily a successful product.

If nobody wants to use it, the quality of the code doesn't matter nearly as much.

Why Wade Shares What He Learns

Wade's development journey wasn't always easy.

There were periods when he almost gave up.

One of the challenges he faced was the cost of education and development resources, particularly because of currency conversion. At one point, the exchange rate made many courses difficult to afford.

He also remembers a time before AI made technical research much easier.

Finding reliable information required significant searching and experimentation.

That experience influenced the way Wade approaches sharing knowledge today.

His goal is straightforward:

Share the tools he uses, explain why he uses them, and show others how to use them.

He wants to make the learning curve easier for someone who might be considering web development as a career path.

There are now countless frameworks, platforms and tools available, and that abundance can itself become overwhelming.

Wade wants his content to help developers make sense of those choices rather than simply telling them which technology is "the best."

Teaching has also improved his own understanding.

Explaining a concept forces you to understand it more deeply.

For Wade, documenting his learning has therefore become part of his own development process.

The more he teaches, the better he understands the technologies he works with.

Advice for Self-Taught Developers

For developers starting their journey today, Wade has a few practical recommendations.

First, choose a programming language with a strong community and learn the fundamentals well.

Don't make learning feel like a punishment.

There will always be difficult periods, but there should also be some enjoyment in the process.

Second, take advantage of the huge amount of free educational material available today.

YouTube has become a valuable learning resource, and AI can also be used as a learning assistant.

Wade recommends exhausting free resources before spending money on courses.

Third, use development roadmaps.

One of the biggest challenges he faced was not knowing what to learn next.

Today, developers have access to many structured roadmaps that can provide direction.

Perhaps most importantly, Wade recommends avoiding the temptation to become a jack of all trades.

Find a technology stack you enjoy and become highly capable with it before constantly adding new technologies.

Don't chase every new framework simply because it is popular.

Change technologies when there is a real reason to do so and when the change genuinely improves your development process.

And when building applications, focus on structure rather than obsessing over syntax.

Before writing code, understand what you want to achieve.

Break the application into components and understand how those components need to interact.

Then start writing the code.

As Wade puts it, understanding structure can eliminate many of the problems that inexperienced developers encounter.

A Journey Built on Learning and Purpose

Wade's journey from telecommunications to full-stack development wasn't planned in a traditional way.

It began with small coding projects, continued through a difficult career transition, and developed through years of self-directed experimentation.

Along the way, he learned that technology is only one part of software development.

Choosing the right tools matters.

Understanding infrastructure matters.

Learning continuously matters.

But understanding the business, the customer and the problem you're trying to solve may matter even more.

His approach today reflects that experience: choose practical technologies, avoid unnecessary complexity, control infrastructure where it makes sense, understand the user and keep learning.

For developers who feel overwhelmed by the constant stream of new frameworks and technologies, Wade's story offers a useful reminder:

You don't need to learn everything. You need to learn enough to solve meaningful problems well.

And perhaps his most personal piece of advice comes from the principle that has helped him throughout the journey:

"As for my secret weapon — whenever I'm stuck looking for a solution, I pray."

About Wade Alister Thomas

His coderlegion profile

Wade Alister Thomas is a self-taught full-stack developer and consultant from Trinidad & Tobago.

His preferred technology stack includes TanStack Start, Tailwind CSS, shadcn/ui, Directus, PostgreSQL, Redis and Coolify-managed VPS infrastructure.

Through Northern Range Digital, he helps businesses establish their online presence and build digital products. He also creates logos and Git templates and regularly shares what he learns through technical articles and guides.

You can learn more about Wade and his work through his CoderLegion profile and website.

Directus Basics Part 3 — User Roles & Permissions

Fri, 21 Aug 2026 06:23:23 +0000

This is part three of our Directus Basics series. In part one we set up our instance, and in part two we covered relationships between collections. Today we're covering access control — what determines who can see and touch your data.

Part III - Youtube

The Core Concepts

Access control in Directus comes down to three terms:

Permission — applies to one collection and one action (create, read, update, delete, or share). Can be full access, no access, or custom rules.
Policy — a group of permissions bundled together, applied to users or roles.
Role — defines a user's position within a project. A role can hold any number of policies, apply to any number of users, and have child roles of its own.

What Happens Without a Role?

If an administrator creates a user but doesn't assign a role, that user has valid login credentials but still can't access the Data Studio.

Creating a role and assigning the user to it isn't enough either — logging in at that point returns a "No App Access" error. The missing piece is that the role has no access policy attached. The policy is what actually tells the role what its users can and can't do.

The Access Order

Access in Directus flows in a specific direction:

Access Policy → Role → User

In practice: define what level of access a user needs, build an access policy to match, create a role and attach that policy to it, then register the user and assign them to the role.

Default Policies

Every fresh Directus instance ships with two default policies:

Administrator — the role you're signed in as by default, with unrestricted access to everything.
Public — for data that should be visible without logging in. Think of a product catalog on an e-commerce site — forcing a login just to browse products is a poor experience.

Rule of thumb: give the Public policy Read access only. Never Create, Update, or Delete. The public should be able to view data, never manipulate it.

Giving a Collection Public Access

Go to Settings → Access Policies → Public
Under Permissions, click Add Collection
Select products
Click Read, choose All Access
Save

Creating a Custom Access Policy

Let's build a policy for a data-entry team member with limited access.

Go to Access Policies, click Create
Name it DataEntry
Check App Access — leave Admin Access unchecked, since that grants unrestricted control
Save

Directus populates the policy with minimum defaults for its own system collections, but nothing for your custom collections yet.

Add products to it:

Click Add Collection, select products
Click Read, choose All Access
Save

Creating the User Role

Go to User Roles, click Create
Name it DataEntry
Under Policies, click Add Existing, select the DataEntry policy
Save

Creating the User

Go to User Directory, click Create
Fill in first name, last name, email, and password
Under Role, select DataEntry
Save

If you check back on User Roles, you'll see a 1 next to DataEntry under Users, and a matching 1 under Access Policies. That confirms the role, policy, and user are all wired together correctly.

Tip: giving your policy and role the same name (as done here with "DataEntry") makes them much easier to track as your project grows.

Testing Read-Only Access

Log in as the new user. You'll see the products collection, but attempting to edit any field does nothing — expected, since only Read access was granted.

Scrolling to the bottom of a product's detail page, some data is simply missing — those fields belong to other collections the user doesn't yet have permission for. The product image is missing too.

Fixing the Missing File Permission

Back in the DataEntry policy, notice directus_files isn't included among the accessible system collections. Without it, uploaded files — including product images — stay invisible.

Click Add Collection, select directus_files
Click Read, choose All Access
Save

Log back in as the data-entry user, and the product image now appears.

Adding the Thumbnail to List View

In list view, click the + icon on the right
Scroll to image, click the arrow next to it — not the field name itself, or you'll add the raw file ID instead of the thumbnail
Scroll to thumbnail, click outside the dropdown to confirm

Drag column headers to reorder them as needed.

The same missing-permission pattern applies to branding, products_tags and tags — add all to the DataEntry policy with Read access, and the relational fields on products become visible.

Key takeaway: you can't access a relational field in one collection unless you also have permission on the related collection. Both sides of the relationship need coverage.

Custom Field-Level Permissions

Sometimes all-or-nothing collection access isn't granular enough. Directus lets you restrict access down to individual fields.

Let's allow the data-entry user to update only the name field on products:

On the products collection, click the Update action
Choose Use Custom
Click Field Permissions
Check Name
Save, then save again

Logging back in, the data-entry user can now edit the Name field — and nothing else on that collection.

Summary

Concept	Definition
Permission	One collection + one action, set to full/none/custom
Policy	A bundle of permissions, applied to users or roles
Role	A user's position in the project; holds policies, applies to users

Access control in Directus is genuinely one of its most powerful features — this covers the fundamentals, but there's plenty more granularity available as your project grows.

That wraps part three. Next up, we'll look at how everything from this series comes together once we start pulling this data into a real front end.

Found this useful? Follow for more Directus and TanStack Start tutorials, or check out the video version above.

Directus Basics Part 2 — Understanding Relationships (M2O, O2M, M2M)

Tue, 18 Aug 2026 00:38:07 +0000

This is part two of our Directus Basics series. In part one, we set up a Directus instance and created our first collection. Today we're covering one of the most powerful features Directus offers: relationships between collections.

By the end of this article, you'll understand three core relationship types — Many to One (M2O), One to Many (O2M), and Many to Many (M2M). There's a fourth type, Many to Any (M2A), which we'll cover in a future post.

Setting Up the Branding Collection

Continuing from our existing Directus instance, let's create a new collection called branding. Select all the additional default fields Directus offers.

Add two fields:

Field	Type
`name`	String (basic input)
`description`	Text (textarea)

Once the collection is set up, add a few entries — I'd recommend at least two different brands so you can see the relationship in action once it's wired up.

Many to One (M2O): Products → Branding

Head over to your products collection. We want to connect a product to a brand.

Logically: many products can belong to one brand. That's a Many to One relationship — many products, to one brand.

Steps:

Create Field → Relational category → Many to One
Key: brand_id
Related Collection: branding
De-select Enable Create Button — you always want to choose a brand from an existing list, not create one on the fly
Save

One to Many (O2M): Branding → Products

Since one brand can have many products, we need to set up the reverse relationship explicitly on the branding collection.

Steps:

Create Field → Relational category → One to Many
Key: products
Related Collection: products
Foreign Key: brand_id — the field we just created on the products side
De-select Enable Create Button
Save

Seeing the Relationship in Action

Go back into your products collection and assign a brand to each product. Make sure at least two products share the same brand so the relationship is visible.

You'll notice each product can only belong to one brand — that's the M2O relationship at work.

Now open the branding collection and click into one of your brands. You'll see the products you just assigned show up automatically — you didn't have to add them manually. Directus handled that because of the relationship you configured.

Many to Many (M2M): Products ↔ Tags

M2M relationships work differently — both sides can have many related records.

A common real-world example: tags on products, used to improve SEO. A single product can have multiple tags, and a single tag can apply to many products.

Create the Tags Collection

Create a new collection called tags, with the same two fields as before:

Field	Type
`name`	String
`description`	Text (textarea)

Add three or four tags before moving on.

Wire Up the M2M Relationship

Back in the products collection:

Create Field → Relational category → Many to Many
Key: tags
Related Collection: tags
De-select Enable Create Button
Do not save yet — scroll down and click "Continue in Advanced Field Creation Mode"
In the sidebar, click Relationship, then find Corresponding Field
Check "Create Field" — under Field Name, you should see products appear
Save

Why the advanced flow? Under Corresponding Field, products appears automatically — that's Directus telling you it's about to create the matching relational field back on the tags collection. Unlike the M2O/O2M setup, you don't have to manually configure both sides — Directus builds the reverse relationship for you.

Now, when you add a tag to a product, Directus automatically links that product under the corresponding tag in the tags collection — no manual syncing required.

Summary

Relationship	Direction	Example
M2O	Many records → one related record	Products → Branding
O2M	One record → many related records	Branding → Products
M2M	Many ↔ many, both directions	Products ↔ Tags

Relationships are one of those Directus features that make a lot more sense once you've built one yourself than they do reading about them — so I'd recommend replicating this setup in your own instance before moving on.

That wraps up part two. In part three, we'll cover Directus permissions — how to control exactly who can see and edit your data.

Found this useful? Follow for more Directus and TanStack Start tutorials, or check out the video version on YouTube.

Directus Collections Explained (Fields, Types & Setup) — Directus Basics Part 1

Fri, 07 Aug 2026 21:18:22 +0000

This is Part 1 of a three-part series on Directus fundamentals: Collections (this post), Relationships, and Permissions. New to Directus? Start here.

Youtube Video - Directus Collections

Introduction

Collections are the bread and butter of the Directus Data Studio. According to Directus's own docs, collections are database tables — with extra metadata and configuration layered on top by Directus.

The part that makes this genuinely beginner-friendly: you never write a single line of SQL. The Data Studio handles all of that for you. Let's build one.

Two Ways to Create a Collection

There are two paths to collection creation inside the Data Studio.

Option 1: Log into your Data Studio and look at the sidebar for the icon that looks like a 3D box — that's Content. Click it, and on the main screen you'll see Create Collection.

Option 2: Scroll down the sidebar to the gear icon — Settings. Click in, and at the top you'll find Data Model. Same deal from there — Create Collection is right on the main screen.

Either path lands you in the same place.

Creating a Collection

Click Create Collection
Name it something intuitive — it should describe exactly what data you're storing. For this example, we're creating a collection called products
Ignore Singleton for now (more on this below)
In the Type dropdown, select Generated UUID
Click Next, select all the boxes offered, and click Finish Setup

What is Singleton? You'd only check this if the collection will ever hold exactly one item — not the case here, since we're storing many products.

What is the Generated UUID? A unique ID automatically assigned to every item in the collection, so you never have to manage IDs manually.

Once created, you land on the collection's screen, ready to build its data structure.

Bonus: under Collection Setup, you can customize how the collection looks — a color, an icon, and a short note describing its purpose. Small detail, but it pays off once your Directus project has a dozen collections in it.

Creating Fields Within a Collection

Fields represent the actual data you're storing — in this case, the data that describes a single product. Every item in the collection shares this same structure, just with different values. Here's the full field breakdown for a products collection:

Field	Type	Notes
`name`	Input (string)	The product's name
`brief`	Textarea	Short description — more room than Input, no special formatting needed
`description`	WYSIWYG	Full rich-text formatting — paragraphs, bullet lists, H1–H4 headings
`price`	Input (decimal)	See Precision & Scale below
`sale`	Input (decimal)	Same setup as `price`
`isOnSale`	Boolean	Toggle the front end can check to decide which price to show
`category`	Dropdown	Product type — e.g. jersey, pants
`quantity`	Input (integer)	Minimum value of 1
`image`	File	Product photo

Setting Up the Price Field (Precision & Scale)

The price field needs a bit of extra configuration. Instead of clicking Save right away, look just below the Save button for Continue in Advanced Field Creation Mode.

In there, you'll find Precision and Scale, defaulting to 10 and 5.

Precision — the total number of digits the field accepts
Scale — how many of those digits sit after the decimal point

Left at the defaults, you'd get something like 12345.67890. For a price field, that's overkill — we want 7 digits total, 2 of them after the decimal point. So: Precision = 7, Scale = 2. Adjust to fit your own use case if you need more decimal precision.

Build sale the exact same way.

Note on relational fields: collection relationships (linking one collection to another) are deliberately left out here — that's a big enough topic to earn its own post, and it's exactly what's coming next in this series.

Adding Your Data

Head to the sidebar and click the box icon — Content. You'll see your Products collection listed. Click Create Item, and fill in the fields with real data.

For this example, add a couple of items — a jersey and a pair of jeans — to see the collection actually holding data.

Summary

That's the foundation of Directus collections: the core field types, how to configure them, and how to get real data in. Next up in this series: relationships — how collections connect to each other, which is where Directus really starts to shine.

Questions or stuck on something? Drop a comment below.

Directus + Coolify: Should You Decouple Postgres & Redis?

Thu, 06 Aug 2026 21:39:55 +0000

This is Part 2 of the Directus + Coolify series. If you're new here, start with "Secure Your VPS Before Hackers Do" and the first Directus + Coolify post — the bundled, single-Compose-file setup — before following along with this one.

Introduction

In the first method, we coupled all of the services into one stack using a single Docker Compose file. The network between all services was created automatically, and we didn't have to start them up individually — which removes the risk of a race condition if service startup isn't handled properly.

If you're running a single app, that's genuinely the recommended way to set up Directus on a Coolify-managed VPS. Going in, I assumed there were several good reasons to split the services apart instead — more control over backups, monitoring, restarts, that kind of thing. So before recommending decoupling, I actually tested each of those assumptions on a live Coolify instance.

Most of them turned out to be wrong.

Myth 1: Restarting Directus Restarts the Whole Stack

I expected that restarting Directus inside the bundled Compose file would restart Redis and Postgres along with it. It doesn't. Coolify lets you restart each service in the stack independently — Directus, Database, and Cache each get their own Restart button, right there in the same view. No decoupling needed for this one.

Myth 2: You Need a Separate Database Resource for S3 Backups

Same story. Even with Postgres bundled inside the Directus Compose file, Coolify still gives it its own dedicated Backups option, S3 included. This isn't a separate-resource-only feature.

Myth 3: Scheduled Tasks Require Separate Services

Also not true. Coolify exposes a Scheduled Tasks tab per service, even inside a single bundled stack — complete with a Container name dropdown letting you target the cron job at just the database, or just Directus, without splitting anything apart.

What Actually Holds Up

Two things survived testing.

First: metrics. This one's confirmed directly in Coolify's own documentation — CPU and memory metrics collection is explicitly not available for Docker Compose–based deployments. If you want to see per-container resource usage through Coolify's built-in monitoring, the service needs to be created as its own standalone resource, not bundled inside a Compose file. This is a real, documented limitation of the bundled approach.

Second: sharing a database across multiple apps. This one isn't a Coolify feature at all — it's just how Docker networking works. A database defined inside one app's Compose file lives on that stack's own private network by default. A second, completely separate application can't reach it without deliberately bridging the two networks. If you've got a desktop app and a mobile app that both need to talk to the same Postgres instance, that database needs to exist as its own standalone resource from the start — it can't stay tucked inside one app's Compose file.

So this really comes down to two reasons to decouple, not five — one a genuine Coolify limitation, the other a structural fact about Docker networking. Let's set both of those up properly.

Adding the Resources

Adding the PostgreSQL Database

Dashboard → Add Project
+ Add Resource
Databases → PostgreSQL → Supabase PostgreSQL (with extensions)
Change the name to something human-friendly
Copy your username and password and save them somewhere — you'll need them shortly
Click Save
Click Start, and wait for the database to spin up (this can take a little while)

Once it's up, the status should read "Running (Healthy)."

💡 Enable metrics while you're here. In the sidebar, go to Servers → localhost → Metrics, and enable metrics. Back in your project, under Databases, click your Postgres database, then Metrics — you should now see live CPU/memory usage for it. This is the exact capability that isn't available on a bundled Compose deployment.

Adding Redis Cache

Dashboard → + Add Resource (from the project itself)
Databases → Redis
Rename it to something more convenient
Copy the Redis connection URL — you'll need it shortly
Save, then Start

Once both are running, SSH into your VPS and run:

docker ps

to confirm both containers are up.

The Docker Compose Config for Directus

This is what goes into the empty Compose file for the Directus resource:

services:
  directus:
    image: 'directus/directus:12.2.0'
    ports:
      - '8055:8055'
    volumes:
      - './uploads:/directus/uploads'
      - './extensions:/directus/extensions'
    healthcheck:
      test:
        - CMD-SHELL
        - 'wget --spider -q http://127.0.0.1:8055/server/ping || exit 1'
      interval: 10s
      timeout: 5s
      retries: 5
      start_interval: 5s
      start_period: 30s
    environment:
      SECRET: secretstring
      MARKETPLACE_TRUST: all
      DB_CLIENT: pg
      DB_HOST:
      DB_PORT: '5432'
      DB_DATABASE: postgres
      DB_USER: postgres
      DB_PASSWORD:
      CACHE_ENABLED: 'true'
      CACHE_STORE: redis
      CACHE_AUTO_PURGE: 'true'
      REDIS:
      ADMIN_EMAIL: *Emails are not allowed*
      ADMIN_PASSWORD: '1234567890'
      CORS_ENABLED: 'true'
      CORS_ORIGIN: 'true'
      CORS_CREDENTIALS: 'true'
      PUBLIC_URL:

Notice the healthcheck already uses 127.0.0.1 instead of localhost — that's the fix from Part 1. Carrying it forward here saves you from hitting the exact same "unhealthy" bug all over again.

Adding Directus

Dashboard → + Add Resource (from the project itself)
Applications → Docker Compose Empty
Paste in the Compose configuration above
Click Save
Network → Connect To Predefined Network → check the box
Services → Directus service → Settings
Add your Directus subdomain — remember to use https:// (e.g. https://directus.yourdomain.com)
Save

Connecting the Services Together

Variable	What it is
`SECRET`	A long, unguessable random string
`DB_HOST`	The name of your Postgres container — run `docker ps` on your VPS to find it
`DB_DATABASE`	The name of the database on your Postgres server (Coolify's default is usually `postgres`, but confirm it against your Postgres service)
`DB_USER`	The database username, from the Postgres service you created earlier
`DB_PASSWORD`	The password from that same Postgres service
`REDIS`	The Redis connection URL from the Redis service you created earlier
`PUBLIC_URL`	Your Directus subdomain

⚠️ Redis URL gotcha: the connection URL follows the format redis://username:password@host:port. Coolify's generated URL includes the username you set when creating the Redis resource — in my case, that username was also redis, so the URL looked like redis://redis:somelongvariable.... Directus doesn't need the username here, just the password, so strip that segment out: redis://:somelongvariable.... If you used a different username when creating your Redis resource, remove that value instead — not literally the word "redis."

Setting Up Environment Variables

Rather than hardcoding any of this directly into the Compose file, move it into Directus's environment variables:

Dashboard → Projects → Services / Directus
Environment Variables
Click + Add, enter the variable name in all caps, and its value
Save
Repeat for: SECRET, DB_HOST, DB_DATABASE, DB_USER, DB_PASSWORD, ADMIN_EMAIL, ADMIN_PASSWORD, and REDIS

Updating the Compose File

Now reference those variables instead of the raw values:

SECRET: '${SECRET}'
DB_HOST: '${DB_HOST}'

...and so on for each variable. Then:

Save
Restart

Launching Directus

Paste your Directus subdomain into the browser, and you should land on your running Directus instance. You can also click Links on the Directus service, then click the subdomain — it'll take you straight to your Directus Studio login.

Same as the last video: sign up for your free license, which arrives by email, and paste it into your Directus instance to unlock everything.

Any questions or hit a different result testing any of these yourself? Drop it in the comments — I'm genuinely curious whether this holds up across different Coolify versions and setups.

Setting Up Directus on a Coolify VPS (And Fixing the "Unhealthy" Error)

Sun, 02 Aug 2026 14:42:21 +0000

Introduction

Directus is a backend for developers. It can connect to any SQL database and asset storage, and it provides developer tooling — which the Directus team calls the "Data Engine" — alongside a web application that lets both developers and non-developers manipulate data and assets through a no-code interface called the "Data Studio."

Directus also offers granular access control, meaning end users can only see, manipulate, and interact with the data allowed by their role and access policy — enforced consistently by both the engine and the studio. It's extensible through its own marketplace, and it's completely free, with a free license available.

Directus is also known as a headless CMS — meaning it doesn't ship with a front end attached out of the box, the way WordPress traditionally did. You can pair it with whichever front end you prefer; TanStack Start is my front end of choice.

In this post, I'll self-host Directus on my Coolify-managed VPS, walk through both setup methods, and — since nothing ever works perfectly on the first try — fix the actual errors I hit along the way.

📌 New here? I'd recommend checking out my earlier posts where I set up the VPS itself and installed Coolify on it, before continuing with this one.

Let's Get Started

There are two ways to set up Directus on a Coolify-managed VPS. I'll cover the first one here.

1. Log in to your Coolify Dashboard

In the sidebar menu, go to Projects → +Add
Give your project a name and description, and press continue

2. Add a Resource

After naming your project, you should be redirected to the project's page, where you can add a resource. If that redirect doesn't happen, click Projects in the sidebar, then click into your project, and you should see +Add Resource.

Click +Add Resource
Under Applications, select Docker Compose Empty
A blank Docker Compose file will open
Go to directus.com → Docs → Hosting → Deployment
Scroll down until you find the example Docker Compose YAML file, and copy it
Paste it into your blank Coolify Compose file
Find the directus: service, and under it, image: — update this to the version you want. As of this post, the latest version is 12.2.0:
```
image: directus/directus:12.2.0
```
Scroll to the end and set your own admin email and password — these become your Data Studio login credentials
Click Save at the top

3. Configure the Service

You should now be on the Configuration screen, with a Deploy button (yellow outline arrow) in the top right.

Under Network, check the box
Under Services, click Settings on the directus tab
In the Domain field, enter your subdomain — e.g. https://directus.yourdomain.com. Use https, so Traefik knows to issue a Let's Encrypt certificate for it
Click Save, then Back
Click Edit Compose File at the top, scroll down to PUBLIC_URL, and set it to match your subdomain:
```
PUBLIC_URL: https://directus.yourdomain.com
```
Click Save, close the modal
Click Deploy, then Confirm on the popup
Wait for the deployment to finish

4. Launch Directus

On the Configuration screen, click Links, then click your new subdomain.

The Errors

At this point, your browser will show two errors: a "Not Secure" warning in the address bar, and a "no available server" page.

Back on the Coolify dashboard, you'll notice the Directus instance is showing as unhealthy. Traefik will not route traffic to a service that's failing its health check — which is exactly what's happening here. So the first job is figuring out why the health check is failing.

Diagnosing the Problem

SSH into your VPS to start digging.

Check your running containers:

sudo docker ps

Install jq, so the JSON output we're about to read is actually readable:

sudo apt install jq

Check the health check failure log (grab your Directus container's name from the docker ps output above):

docker inspect --format='{{json .State.Health}}' <your-directus-container-name> | jq

The result looked like this:

{
  "Status": "unhealthy",
  "FailingStreak": 79,
  "Log": [
    {
      "Start": "2026-07-30T18:12:21.445964902-04:00",
      "End": "2026-07-30T18:12:21.502447668-04:00",
      "ExitCode": 1,
      "Output": "wget: can't connect to remote host: Connection refused\n"
    },
    {
      "Start": "2026-07-30T18:12:31.505411263-04:00",
      "End": "2026-07-30T18:12:31.556307544-04:00",
      "ExitCode": 1,
      "Output": "wget: can't connect to remote host: Connection refused\n"
    }
  ]
}

The first clue: "wget: can't connect to remote host: Connection refused". Whatever endpoint the health check is trying to reach, it's being actively refused — not timing out, refused. That distinction matters, and it's the thread that leads to the actual fix.

Inspecting the Docker Compose File

From the Coolify dashboard, select Projects in the sidebar
Click your project
Click the service, then Edit Compose File next to Service Stack

Here's the relevant section:

directus:
  image: 'directus/directus:12.2.0'
  ports:
    - '8055:8055'
  volumes:
    - './uploads:/directus/uploads'
    - './extensions:/directus/extensions'
  depends_on:
    database:
      condition: service_healthy
    cache:
      condition: service_healthy
  healthcheck:
    test:
      - CMD-SHELL
      - 'wget --spider -q http://localhost:8055/server/ping || exit 1'
    interval: 10s
    timeout: 5s
    retries: 5
    start_interval: 5s
    start_period: 30s

The problem is in the wget line — specifically, http://localhost:8055.

Why `localhost` Breaks This

Inside a Linux container, localhost isn't an address — it's a hostname that has to be resolved first, and it typically maps to two addresses at once:

127.0.0.1   localhost   # IPv4
::1         localhost   # IPv6

When wget looks up localhost, the system's resolver hands back both addresses, and wget tries them in whatever order it receives them — which, on many Linux/Alpine base images, tends to prefer IPv6 first.

Checking the container's logs confirms what's actually listening:

docker logs <your-directus-container-name> --tail 150

Directus only bound to IPv4. The startup log says exactly that:

Server started at http://0.0.0.0:8055

0.0.0.0 means "listen on every IPv4 interface" — Directus never opened an IPv6 socket at all. So when wget tries ::1:8055 first, there's genuinely nothing listening there, and the OS doesn't wait around wondering — it immediately sends back a rejection (a TCP RST). That's exactly why the log shows an instant "Connection refused" rather than a slow timeout. A timeout would mean something was reachable but not responding; a refusal means the OS said "nothing's here" right away.

127.0.0.1 sidesteps the whole problem, because it's already a literal IP address — no hostname lookup, no ambiguity about which protocol family to try, no chance of picking the wrong one. It goes straight to the one address where Directus is actually listening.

The Fix

Change localhost to 127.0.0.1 in the health check:

directus:
  image: 'directus/directus:12.2.0'
  ports:
    - '8055:8055'
  volumes:
    - './uploads:/directus/uploads'
    - './extensions:/directus/extensions'
  depends_on:
    database:
      condition: service_healthy
    cache:
      condition: service_healthy
  healthcheck:
    test:
      - CMD-SHELL
      - 'wget --spider -q http://127.0.0.1:8055/server/ping || exit 1'
    interval: 10s
    timeout: 5s
    retries: 5
    start_interval: 5s
    start_period: 30s

Save the change, close the modal, and click Restart in the top right. Wait for the restart to complete — it may look like nothing's happening for a bit, so give it a moment. Once it's finished, close the logs modal, and Directus should show as healthy.

Click Links, then your Directus subdomain, and you should land on the Data Studio login screen.

Logging In & Licensing

Enter the credentials you set earlier in the Compose file. You'll be asked whether you have a license or want to install the Core — choose Core for now, and follow the flow to complete sign-up.

At this stage, your instance isn't fully unlocked — you'll need a license. Good news: it's completely free if your business's revenue is under $5M and your team is under 50 people.

Head to directus.com/oig to apply for your key. Once you have it, go to your Directus Studio, click the gear icon (Settings) in the sidebar, click License, and add your key there to unlock all features. Your key is valid for a year.

Got questions, or hit a different error setting this up? Drop a comment below — happy to help troubleshoot.

Coder Legion - Recent posts tagged directus

TanStack Start Basics Part 2 — Connecting to Your Directus Backend

Installing the Directus SDK

Creating the Directus Helper

Defining Our First Type

Writing the Fetch Function

Fixing the Schema Error

Fetching the Data — Method 1: TanStack Query

Fetching the Data — Method 2: Route Loaders

Which One Should You Use?

Summary

Setting Up Our Frontend with TanStack Start

What Is TanStack Start?

Creating the Project

Walking Through the Setup Prompts

Running the App

Editing the Home Page

File-Based Routing

Adding an About Page

Adding a Products Page

What Is That __root.tsx File?

Summary

From Retrenchment to Full-Stack Developer: Wade Thomas on Learning, Simplicity and Building Software

From Retrenchment to Full-Stack Developer: Wade Thomas on Learning, Simplicity and Building Software That Matters

From 2014 to 2018: When a Career Changed Direction

The Challenge of Being a Self-Taught Developer

Finding a Stack That Works

Why Wade Chose Self-Hosting

Why Directus Became an Important Part of His Stack

When Simplicity Becomes an Architecture Principle

From Developer to Consultant

Building More Than Software

Why Wade Shares What He Learns

Advice for Self-Taught Developers

A Journey Built on Learning and Purpose

About Wade Alister Thomas

Directus Basics Part 3 — User Roles & Permissions

The Core Concepts

What Happens Without a Role?

The Access Order

Default Policies

Giving a Collection Public Access

Creating a Custom Access Policy

Creating the User Role

Creating the User

Testing Read-Only Access

Fixing the Missing File Permission

Adding the Thumbnail to List View

Extending Access to Related Collections

Custom Field-Level Permissions

Summary

Directus Basics Part 2 — Understanding Relationships (M2O, O2M, M2M)

Setting Up the Branding Collection

Many to One (M2O): Products → Branding

One to Many (O2M): Branding → Products

Seeing the Relationship in Action

Many to Many (M2M): Products ↔ Tags

Create the Tags Collection

Wire Up the M2M Relationship

Summary

Directus Collections Explained (Fields, Types & Setup) — Directus Basics Part 1

Introduction

Two Ways to Create a Collection

Creating a Collection

Creating Fields Within a Collection

Setting Up the Price Field (Precision & Scale)

Adding Your Data

Summary

Directus + Coolify: Should You Decouple Postgres & Redis?

Introduction

Myth 1: Restarting Directus Restarts the Whole Stack

Myth 2: You Need a Separate Database Resource for S3 Backups

Myth 3: Scheduled Tasks Require Separate Services

What Actually Holds Up

Adding the Resources

Adding the PostgreSQL Database

Adding Redis Cache

The Docker Compose Config for Directus

Adding Directus

Connecting the Services Together

What Is That `__root.tsx` File?

Why `localhost` Breaks This