lovelace-soft-ui draws Home Assistant cards with paired shadows

A theme, not a plugin, and it says it is finished

The lovelace-soft-ui repository is a neumorphic theme for Home Assistant Lovelace, with elegant soft shadows, light and dark modes, and a set of reusable card components.

The first thing the README says is that the project is archived and no longer maintained, and that it remains available as a reference for anyone exploring neumorphic UI in Home Assistant. The README also points to a community forum thread for discussion and examples from other users, and thanks everyone who used, contributed or shared feedback on the project.

That framing matters for what follows, because it tells you what kind of thing this is. It is a finished artifact rather than a project in progress. There is nothing to wait for, and no upstream to track, because the repository is a snapshot of a design idea that its author has moved on from.

The topics on the repository are css, home-assistant, lovelace, neumorphism and soft-ui, and the whole repository is four entries: a LICENSE file, the README, a cards/ directory and an images/ directory. There is no application code and no build system, which is exactly right for what this is. It is a handful of YAML files and some screenshots.

The audience is a Home Assistant user who has seen the neumorphic style elsewhere, wants it on their dashboard, and is comfortable editing theme YAML. The licence is MIT, the default branch is main, and the last push to the repository was on 2026-07-04.

The whole effect is two box shadows

The mechanism is CSS box-shadow, and understanding it is enough to adapt the theme to your own cards.

A neumorphic element is drawn as if it were pushed out of the background. The technique is two shadows on the same element: a light shadow offset in one direction, and a dark shadow offset in the opposite direction, with the element's background matching the shadow colour. The light shadow reads as a highlight on the top left, the dark one as a shadow on the bottom right, and the two together make the card look embossed rather than dropped on top of the page.

The light theme does it like this:

# Light
theme_name:
  card-mod-theme: theme_name
  card-mod-card: |
    ha-card {
      margin: 20px;
      border-radius: 15px;
      background-color: var(--primary-background-color);
      box-shadow: -5px -5px 15px #ffffff, 5px 5px 15px #ebebeb;
    }
  soft-ui-pressed: 'inset -4px -4px 5px #ffffff, inset 4px 4px 5px #ebebeb'

And the dark theme uses the same geometry with the two colours swapped for dark greys:

# Dark
theme_name:
  card-mod-theme: theme_name
  card-mod-card: |
    ha-card {
      margin: 20px;
      border-radius: 15px;
      background-color: var(--primary-background-color);
      box-shadow: -5px -5px 15px #2c2c2c, 5px 5px 15px #191919;
    }
  soft-ui-pressed: 'inset -4px -4px 5px #2c2c2c, inset 4px 4px 5px #191919'

Two details are worth noticing. The background colour is not a hard coded value but the Home Assistant CSS variable for the primary background, so the card sits on whatever the theme's background is. And the pressed state is a separate theme variable, soft-ui-pressed, using inset shadows, which is what makes a button look pushed in rather than raised when it is active. That is the whole visual language, and it is short enough to adapt by hand.

Universal or per card, decided by one selector

There are two ways to apply the theme, and the difference between them is a single CSS selector.

The universal route styles every ha-card in the dashboard. The individual route styles only cards that carry the soft-ui class, by changing the selector to ha-card.soft-ui:

# Light
theme_name:
  card-mod-theme: theme_name
  card-mod-card: |
    ha-card.soft-ui {
      margin: 20px;
      border-radius: 15px;
      background-color: var(--primary-background-color);
      box-shadow: -5px -5px 15px #ffffff, 5px 5px 15px #ebebeb;
    }
  soft-ui-pressed: 'inset -4px -4px 5px #ffffff, inset 4px 4px 5px #ebebeb'

And then the class is referenced from any card with the card_mod key:

card_mod:
  class: soft-ui

For a dashboard with mixed content, the individual route is the one to use, because it lets you keep the neumorphic cards and leave, say, a weather card or a map card in the default style. It also means the styling decisions belong to the card rather than to the dashboard, which is the right way round when you are hand editing YAML.

The implementation depends on card-mod, which the README requires and says to install via HACS. The theme uses card-mod's theme and card keys, card-mod-theme and card-mod-card, which is how card-mod is told which theme and which style to apply. The theme file itself goes in the Home Assistant theme directory, at config/themes/{theme_name}/{theme_name}.yaml, and the name inside the file has to match the directory name, since the two places where the theme name appears, the card-mod-theme value and the top level key, are how card-mod finds the rules to apply.

So the installation has three parts: card-mod from HACS, a theme file at that path, and the class on the cards you want styled.

The theme is a skin, and the skin has three dependencies

It is worth being clear about the boundary of what this repository does, because the word theme can be read in two ways.

A Lovelace theme in Home Assistant sets colours, fonts and sizes for the interface as a whole. This repository does not do that. It sets a style for cards, and it does so through card-mod, a separate project that takes a style definition and applies it to the cards you mark. The theme file contributes the card-mod-theme key, which names the theme, and the card-mod-card key, which holds the CSS, and the soft-ui-pressed variable, which is the inset shadow pair for the pressed state.

That means the style only reaches the elements card-mod can reach. A card that does not carry the card_mod class, or a custom card that card-mod does not know how to target, keeps the default Lovelace look. That is by design in the individual variant, and it is also the reason the button cards in the library need a second dependency: the button-card project is a custom card implementation, and the soft UI treatment of a button is applied to it in the same way, through card-mod, from the same YAML.

So the full chain is three projects deep. HACS installs card-mod, card-mod applies this theme, and the button cards additionally need button-card to exist as a card in the dashboard at all. Each link is somebody else's maintenance stream.

For a user in 2026 that is the practical cost of an archived theme, and the reason the README's pointer to the community thread matters. The YAML is short enough to maintain yourself, the card-mod keys are unlikely to change shape, and the theme itself is a finished design. But the honest expectation is that you are the maintainer of your own dashboard styling now, and this repository is where you got the design.

The card library, and the button cards need another project

The cards/ directory holds the reusable pieces, and the README lists them with a screenshot and a path for each.

There is a text heading card, a heading and subheading card, and then a family of button cards: a plain button, a button with a border, a button with text, a button with border text, and a button with a description. The paths follow the same structure, with cards/text/heading.yaml and cards/button/button.yaml and its variants.

The dependency to know about is button-card. The README states that button cards require button-card, a separate custom card project, while the heading cards need nothing beyond what the theme already requires. It also says to add cards via the Manual card option in the Lovelace user interface, which is how you paste a card configuration in rather than using the visual editor.

That last instruction is the practical difference between this repository and a Home Assistant dashboard built with the visual editor. A manual card is YAML, so it is versionable, diffable and easy to copy between dashboards, and it is the only way to attach the card_mod class anyway. The cost is that you are editing YAML by hand, and that two of the card families depend on a third party custom card project that has its own maintenance status.

The images/ directory holds the screenshots, one for each card plus a combined light and dark screenshot of the whole theme, which is how a reader decides whether the style suits them before installing anything.

Why an archived theme is still a useful one

There is a case for keeping an archived project in the ecosystem, and this one makes it explicitly.

The README says it remains available as a reference for anyone exploring neumorphic UI in Home Assistant, and points to a community forum thread for discussion and examples from other users. That thread is the live part of the project. When the code stops, the conversation about how to apply the style continues in a place where other people are actively posting their own configurations.

So the artefact is a starting point rather than an install-and-forget. The YAML is short, the effect is two box shadows, and the part that would normally be the hard work, getting the light and dark palettes right against a Home Assistant background, is already done and written down. Somebody picking this up in 2026 is taking a finished design and a working light and dark pair, and adjusting the geometry, the radius, the margin and the two shadow colours to their own dashboard.

The honest caveat is the one the README already makes. Nothing here is going to be updated for a Lovelace change, and the theme uses card-mod keys, card-mod-theme and card-mod-card, and the card_mod class key, so if card-mod or Lovelace change how those work, the theme will need adjusting by whoever is maintaining it at that point.

For a Home Assistant user who likes the style, that is a small price for a design that would take an afternoon to get wrong from scratch. For a platform team that wants a maintained component with a support commitment, the answer is somewhere else entirely, and the archive notice is the signal to look for it.

Editorial conclusion

Adopt lovelace-soft-ui if you want the soft UI look in Home Assistant and you are willing to work from a frozen snapshot, using it as a reference and adapting the YAML to your own cards. Do not adopt it as a maintained theme, because the README states the project is archived and no longer maintained, and the last push was on 2026-07-04. Before you install anything, read the community forum thread the README links, check that card-mod is installed through HACS, and confirm the card-mod and Lovelace versions in your Home Assistant still accept the card-mod-card and card_mod keys this theme uses.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. qiz-li/lovelace-soft-ui on GitHub
4. README